> I see the c/c++ calls symbols do appear on the stack back trace however for
> Java methods I see the hex addresses (e.g. 0xffffffff70e2322c
> 0xffffffff70c3cd98) - if I do pstack on the thread for this code (many times )
> I may get the symbolic name (mangeled c++ name) for the Java method.
On newer JVMs (1.4.2 and later I believe), the jstack action will perform the
translation to symbolic Java method names. In some situations, you may need
to change the default number of stack frames and bytes of symbolic Java data:
jstack(frames, bytes)
The symbolic translation is performed by a DTrace helper built into the JVM.
There are some situations in which that helper is known to be deficient. On
x86 platforms if the JVM is invoked with the -server option, you will not see
the full stack trace. Further, if there are inlined functions, the helper
may not pick those up whereas pstack(1) can. These are bugs that the Java team
is aware of.
> I've never played with Java & DTrace, but if the regular pid provider is
> anything to go by, this happens because the stack is recorded at the time
> the probe fires, but the matching of addresses to symbols happens somewhat
> later. If the application being traced has meanwhile disappeared, there's
> nothing to match to, and you get hex output.
Java symbol name resolution does not work in the same way as ustack() for
normal ELF symbols (i.e. C and C++).
Adam
--
Adam Leventhal, Fishworks http://blogs.sun.com/ahl
_______________________________________________
dtrace-discuss mailing list
[email protected]
