[PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files

[Maynard Johnson]

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 <maynardj at us.ibm.com> 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]
>>
>