Discussion:
[newb] jstack broken on OS X?
(too old to reply)
Adam Cath
2011-03-25 18:15:40 UTC
Permalink
Raw Message
Hi folks,

I can't get jstack() to yield meaningful results for any Java program on my
Mac. Here's what I've tried:

1) dtrace -n 'hotspot*:::method-entry { trace(copyinstr(arg1, arg2));
jstack(); }'
2) Launch my app with -XX:+ExtendedDTraceProbes

And I get two types of results:
---------------
5 32730
_ZN13SharedRuntime19dtrace_method_entryEP10JavaThreadP13methodOopDesc:method-en
try java/lang/Object
libclient.dylib`JVM_RaiseSignal+0x7cb5b
0x3fcafd0
0x4002ff4
0x380439d
0x3801374
libclient.dylib`JVM_Lseek+0x2317c
libclient.dylib`JVM_Lseek+0x22f24
libclient.dylib`JVM_StartThread+0xa4f
libclient.dylib`JVM_StartThread+0x954
libclient.dylib`JVM_StartThread+0x8e3
libclient.dylib`JVM_StartThread+0x756
libclient.dylib`JVM_StartThread+0x605
libclient.dylib`JNI_CreateJavaVM_Impl+0xc9fe
libSystem.B.dylib`_pthread_start+0x159
libSystem.B.dylib`thread_start+0x22

---------------
6 32730
_ZN13SharedRuntime19dtrace_method_entryEP10JavaThreadP13methodOopDesc:method-en
try org/eclipse/swt/internal/carbon/OS
libclient.dylib`JVM_RaiseSignal+0x7cb5b
0x3ca3d5e
0x3d56ab4
0x3803ec1
0x3803fe5
0x3803fe5
0x380439d
0x3803ec1
0x3803fe5
0x3803fe5
0x3804503
0x3804503
0x3804027
0x3804027
0x3804027
0x3801374
libclient.dylib`JVM_Lseek+0x2317c
libclient.dylib`JVM_Lseek+0x22f24
libclient.dylib`JVM_Lseek+0x22efa
libclient.dylib`JVM_NewInstanceFromConstructor+0xcf2
libclient.dylib`JVM_InvokeMethod+0x401
libclient.dylib`JVM_InvokeMethod+0x178
libjvmlinkage.dylib`JVM_InvokeMethod+0x4f
libjava.jnilib`Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x26
0x3811490
0x3804027
0x3804027
0x3804503
0x3804027
0x3803ec1
0x3803ec1
0x3803fe5
0x3801374
libclient.dylib`JVM_Lseek+0x2317c
libclient.dylib`JVM_Lseek+0x22f24
libclient.dylib`JVM_Lseek+0x22efa
libclient.dylib`JVM_FindLoadedClass+0xe05
libclient.dylib`JVM_FindLoadedClass+0xc84
java`0x358f
java`0x5b66
Foundation`__NSThreadPerformPerform+0x1fa
CoreFoundation`__CFRunLoopDoSources0+0x61b
CoreFoundation`__CFRunLoopRun+0x42f
CoreFoundation`CFRunLoopRunSpecific+0x1c4
CoreFoundation`CFRunLoopRunInMode+0x61
java`0x51b6
java`0x4bdf
java`0x2335
java`0x27
---------------

These stacks are not terribly informative. It seems unlikely that every
single Java method is called by JVM_RaiseSignal. And of course, there are
those long chains of symbol-less frames, including several which claim to be
recursive (0x3804027 recurs twice? Really?).

Some data points: dtrace does correctly print out the method names, so it is
managing to get some symbol information. Also, the jstack command-line
utility works correctly for the same process.

I'm on Mac OS 10.6.6, using the Apple JVM (I've tried 1.5 and 1.6). I get
the same behavior regardless of what program I run. I asked dap to try it on
his machine and he gets similar nonsense.
Adam Leventhal
2011-03-27 01:07:51 UTC
Permalink
Raw Message
Hey Adam,

As you probably figured out, those two stacks contain a bunch of JITed
code. The hotspot JVM should provide the facilities for DTrace to
interpret those symbolically. Printing of C symbols use an orthogonal
-- and far simpler -- mechanism.

Can someone from the Apple team comment on this?

Adam
Post by Adam Cath
Hi folks,
I can't get jstack() to yield meaningful results for any Java program on my
1) dtrace -n 'hotspot*:::method-entry { trace(copyinstr(arg1, arg2));
jstack(); }'
2) Launch my app with -XX:+ExtendedDTraceProbes
---------------
5 32730
_ZN13SharedRuntime19dtrace_method_entryEP10JavaThreadP13methodOopDesc:method-en
try java/lang/Object
libclient.dylib`JVM_RaiseSignal+0x7cb5b
0x3fcafd0
0x4002ff4
0x380439d
0x3801374
libclient.dylib`JVM_Lseek+0x2317c
libclient.dylib`JVM_Lseek+0x22f24
libclient.dylib`JVM_StartThread+0xa4f
libclient.dylib`JVM_StartThread+0x954
libclient.dylib`JVM_StartThread+0x8e3
libclient.dylib`JVM_StartThread+0x756
libclient.dylib`JVM_StartThread+0x605
libclient.dylib`JNI_CreateJavaVM_Impl+0xc9fe
libSystem.B.dylib`_pthread_start+0x159
libSystem.B.dylib`thread_start+0x22
---------------
6 32730
_ZN13SharedRuntime19dtrace_method_entryEP10JavaThreadP13methodOopDesc:method-en
try org/eclipse/swt/internal/carbon/OS
libclient.dylib`JVM_RaiseSignal+0x7cb5b
0x3ca3d5e
0x3d56ab4
0x3803ec1
0x3803fe5
0x3803fe5
0x380439d
0x3803ec1
0x3803fe5
0x3803fe5
0x3804503
0x3804503
0x3804027
0x3804027
0x3804027
0x3801374
libclient.dylib`JVM_Lseek+0x2317c
libclient.dylib`JVM_Lseek+0x22f24
libclient.dylib`JVM_Lseek+0x22efa
libclient.dylib`JVM_NewInstanceFromConstructor+0xcf2
libclient.dylib`JVM_InvokeMethod+0x401
libclient.dylib`JVM_InvokeMethod+0x178
libjvmlinkage.dylib`JVM_InvokeMethod+0x4f
libjava.jnilib`Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x26
0x3811490
0x3804027
0x3804027
0x3804503
0x3804027
0x3803ec1
0x3803ec1
0x3803fe5
0x3801374
libclient.dylib`JVM_Lseek+0x2317c
libclient.dylib`JVM_Lseek+0x22f24
libclient.dylib`JVM_Lseek+0x22efa
libclient.dylib`JVM_FindLoadedClass+0xe05
libclient.dylib`JVM_FindLoadedClass+0xc84
java`0x358f
java`0x5b66
Foundation`__NSThreadPerformPerform+0x1fa
CoreFoundation`__CFRunLoopDoSources0+0x61b
CoreFoundation`__CFRunLoopRun+0x42f
CoreFoundation`CFRunLoopRunSpecific+0x1c4
CoreFoundation`CFRunLoopRunInMode+0x61
java`0x51b6
java`0x4bdf
java`0x2335
java`0x27
---------------
These stacks are not terribly informative. It seems unlikely that every
single Java method is called by JVM_RaiseSignal. And of course, there are
those long chains of symbol-less frames, including several which claim to be
recursive (0x3804027 recurs twice? Really?).
Some data points: dtrace does correctly print out the method names, so it is
managing to get some symbol information. Also, the jstack command-line
utility works correctly for the same process.
I'm on Mac OS 10.6.6, using the Apple JVM (I've tried 1.5 and 1.6). I get
the same behavior regardless of what program I run. I asked dap to try it on
his machine and he gets similar nonsense.
_______________________________________________
dtrace-discuss mailing list
--
Adam Leventhal, Delphix
http://dtrace.org/blogs/ahl

275 Middlefield Road, Suite 50
Menlo Park, CA 94025
http://www.delphix.com
James McIlree
2011-03-28 20:07:27 UTC
Permalink
Raw Message
Post by Adam Leventhal
Hey Adam,
As you probably figured out, those two stacks contain a bunch of JITed
code. The hotspot JVM should provide the facilities for DTrace to
interpret those symbolically. Printing of C symbols use an orthogonal
-- and far simpler -- mechanism.
Can someone from the Apple team comment on this?
Yes, this is broken, and there isn't really a workaround.

All of the "helper" stack tracers are currently disabled :-(.

It's bug #5273057 if you want to add comments.

I don't currently have an ETA for a fix.

James M
Adam Cath
2011-03-28 20:23:33 UTC
Permalink
Raw Message
Bummer. Whose bugbase are we talking about, and is it open?
Post by James McIlree
Post by Adam Leventhal
Hey Adam,
As you probably figured out, those two stacks contain a bunch of JITed
code. The hotspot JVM should provide the facilities for DTrace to
interpret those symbolically. Printing of C symbols use an orthogonal
-- and far simpler -- mechanism.
Can someone from the Apple team comment on this?
Yes, this is broken, and there isn't really a workaround.
All of the "helper" stack tracers are currently disabled :-(.
It's bug #5273057 if you want to add comments.
I don't currently have an ETA for a fix.
James M
James McIlree
2011-03-28 21:18:58 UTC
Permalink
Raw Message
Post by Adam Cath
Bummer. Whose bugbase are we talking about, and is it open?
It's an Apple bug, I believe the access site is bugreport.apple.com

You will need an ADC membership, I think this is still the current registration site: http://developer.apple.com/programs/register/

James M

Loading...