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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20110325/810f5da5/attachment.html>
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 On Fri, Mar 25, 2011 at 11:15 AM, Adam Cath <adam.cath at gmail.com> wrote:> 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. > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >-- Adam Leventhal, Delphix http://dtrace.org/blogs/ahl 275 Middlefield Road, Suite 50 Menlo Park, CA 94025 http://www.delphix.com
On Mar 26, 2011, at 6:07 PM, Adam Leventhal wrote:> 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
Bummer. Whose bugbase are we talking about, and is it open? On Mon, Mar 28, 2011 at 1:07 PM, James McIlree <jmcilree at apple.com> wrote:> > On Mar 26, 2011, at 6:07 PM, Adam Leventhal wrote: > > > 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 > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20110328/56b7f184/attachment.html>
On Mar 28, 2011, at 1:23 PM, Adam Cath wrote:> 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
On Mon, Mar 28, 2011 at 1:07 PM, James McIlree <jmcilree at apple.com> wrote:> > On Mar 26, 2011, at 6:07 PM, Adam Leventhal wrote: > > > 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. >A number of people have asked me about ustack helpers on OSX, since this is often the first level of observability people need for dynamic environments like Java, Node.js, and Python. I''ve been referring people to this thread. My understanding is that the best way to escalate this to Apple is either through any Apple developer liasons you''re already in touch with or else by filing additional bug reports at bugreport.apple.com (because as far as I know, there''s no way to "vote" on a bug that you didn''t submit). I just filed 11206497. -- Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20120407/ac2efedf/attachment.html>