[newb] jstack broken on OS X?

[Adam Cath]

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]

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

[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

[Adam Cath]

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]

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