UnsatisfiedLinkError and stracktraces
Christian Thalinger
twisti at complang.tuwien.ac.at
Fri Oct 5 15:02:32 PDT 2007
On Fri, 2007-10-05 at 13:30 -0700, Tom Rodriguez wrote:
> > 1. Is there somewhere a specification of what methods need to be in the
> > stacktrace? Would it also be OK to print something like this:
> >
> > java.lang.UnsatisfiedLinkError: nsub
> > at java.lang.Throwable.fillInStackTrace(Native Method)
> > at java.lang.Throwable.<init>(Throwable.java:214)
> > at java.lang.Error.<init>(Error.java:67)
> > at java.lang.LinkageError.<init>(LinkageError.java:54)
> > at java.lang.UnsatisfiedLinkError.<init>(UnsatisfiedLinkError.java:53)
> > at extest.nsub(Native Method)
> > at extest.main(extest.java:336)
>
> I don't think there's a specification of what should be in a stack trace other
> than the vague language that they are precise. The standard logic we use for
> recording stack traces skips the exception constructor frames since they're
> really just noise. I think some printing functions for chained exceptions will
> only dump a few frames of the stack trace and wasting five of them may make
> those printouts less useful. With the Throwable.getStackTrace API it's possible
> to programmatically inspect trace information which could conceivably expose
> differences between implementations but that seems like stretch.
Yes, I agree they are just noise. I only showed this example to make my
point clear.
>
> > 2. What is the reason the failing native method is in the stacktrace?
> > Actually it isn't called. I guess it's something about the way native
> > methods are called in HotSpot (e.g. native stubs). Would this be OK
> > too:
> >
> > java.lang.UnsatisfiedLinkError: extest.nsub()V
> > at extest.main(extest.java:336)
>
> I believe that at the point we throw it we've already pushed a frame for the
> native method so we could start invoking it and then we discover that we can't
> link it which is why it shows up in the call stack. I can't think of any reason
> why one would be preferred over the other.
So we could simply leave the native one out.
- twisti
More information about the hotspot-dev
mailing list