On 12/03/2014 02:24 AM, Volker Simonis wrote: > Hi Maynard, > > if you don't mind please post the next mail to the mailing list > thread. I think these problems and discussions may be helpfull for > others as well (e.g. people doing another port). > > On Wed, Dec 3, 2014 at 12:40 AM, Maynard Johnson <[email protected]> wrote: >> On 12/01/2014 05:16 PM, Maynard Johnson wrote: >>> On 11/25/2014 12:40 PM, Volker Simonis wrote: >>>> Hi Maynard, >>>> >>>> so here finally comes my version of your change. I've tested 'jstack' >>>> with no, '-F' and '-m' flags on PIDs and core files on BigEndian >>>> Linux/PPC64 and it seems to work quite stable now. I've also done some >>>> basic tests with 'jmap' with no, '-histo' and '-F' flags and 'jinfo'. >>> Hi, Volker, >>> Thank you very much for your help with the patch I posted. >>> I tried out your new patch and my results aren't quite as expected. I >>> wonder >>> if I need to update my source tree as it's a few weeks old by now. Anyway, >>> running 'jstack `which java` core', I usually get something like the >>> following >>> for the thread that's running the actual java app code: >>> >>> --------------------------------- >>> Thread 22585: (state = IN_JAVA, current Java SP = null >>> ) >>> - test.main(java.lang.String[]) @bci=100, line=54, pc=0x00003fff8800953c, >>> Method*=0x00003fff7dc00998 (Interpreted frame) >>> --------------------------------- >>> >>> As you can see, there's no compiled frame output where I expect I should >>> see something. >>> I get this pretty consistently on both BE and LE. I also see the same thing >>> running 'jstack -F <pid>' >>> on BE. But unfortunately, neither 'jstack -F <pid>' nor 'jmap <pid>' are >>> working at all on LE right now; >>> instead, I get the following error (which I'm investigating): >>> >>> Error attaching to process: sun.jvm.hotspot.debugger.DebuggerException: >>> Can't attach to the process >> Hi Volker, >> I discovered that the hotspot debugger's call to ptrace was failing with >> errno of EPERM. This doesn't make sense >> to me since I'm running both the java app session and the 'jstack -F' >> session under my normal user account. > > If you're running on Debian/Ubuntu it is probably this issue: > > https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Protection > > which can be solved by doing: > > echo 0 > /proc/sys/kernel/yama/ptrace_scope Yes, that was the issue. Thanks for the tip!
> > or set ptrace_scope to 0 in /etc/sysctl.d/10-ptrace.conf > > >> But when I ran the 'jstack -F' under root, it worked -- sort of. I get the >> following stack: >> >> Thread 44376: (state = IN_JAVA) >> - java.lang.String.getChars(int, int, char[], int) @bci=1, line=805 >> (Compiled frame; information may be imprecise) >> - test.main(java.lang.String[]) @bci=100, line=54 (Interpreted frame) >> >> Line #54 is a call to test.run_test, so I expected to see that in the stack >> (I was running the test java app with >> "-XX:-Inline"). >> > > I don't think we will ever manage to get this 100% correct. The > problem is that Java stacks are only guaranteed to be walkable at > safepoints. That's what happens when we use plain jstack. 'jstack -F' > or jstak on a core file may catch the threads in a state where sp/pc > are in an inconsistent state. I don't think there's much we can do > about it. I think the corresponding output on Linux/x86 isn't perfect > either. Yes, indeed. I looked more closely at my x86 stack output, and I see what you mean. -Maynard > >> I'll see if I can make more progress tomorrow. >> >> -Maynard >>> >> [snip] >> >
