On 11/17/2014 01:21 PM, Volker Simonis wrote:
> On Mon, Nov 17, 2014 at 6:59 PM, Maynard Johnson <mayna...@us.ibm.com> wrote:
>> On 11/17/2014 10:20 AM, Volker Simonis wrote:
>>> Hi Maynard,
>>>
>>> I'm currently looking at your changes. At first glance they look good.
>>>
>>> I could open a simple core file which contained both, interpreted and
>>> compiled frames:
>>>
>>> $ jstack ./images/j2sdk-image/bin/java core.7034
>>> ...
>>> Thread 7035: (state = IN_VM)
>>> - sun.misc.Unsafe.putAddress(long, long) @bci=0 (Interpreted frame)
>>> - Crash.crashIt(sun.misc.Unsafe, int) @bci=10, line=8 (Interpreted frame)
>>> - Crash.doIt() @bci=45, line=23 (Compiled frame)
>>> - sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method,
>>> java.lang.Object, java.lang.Object[]) @bci=0 (Interpreted frame)
>>> - sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object,
>>> java.lang.Object[]) @bci=100, line=62 (Interpreted frame)
>>> - sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object,
>>> java.lang.Object[]) @bci=6, line=43 (Interpreted frame)
>>> - java.lang.reflect.Method.invoke(java.lang.Object,
>>> java.lang.Object[]) @bci=56, line=498 (Interpreted frame)
>>> - Crash.main(java.lang.String[]) @bci=32, line=31 (Interpreted frame)
>>>
>>> The one thing that doesn't currently work is "jstack -m" (i.e. "mixed
>>> mode" for java and native frames). Are you aware of this?
>> Hi, Volker,
>> Yeah, I knew about this problem and forgot to mention it in my patch
>> posting. I started
>> looking at it this morning, and so far, I have at least fixed the
>> UnmappedAddressException.
>> But now I'm getting different results on little endian vs big endian ppc64
>> systems.
>> On BE, I either get no symbol names (i.e., "?????") or wrong symbol names.
>> On LE,
>> I seem to get correct symbol names for the first symbol (either
>> __pthread_cond_wait
>> or __pthread_cond_timedwait) and the last symbol (start_thread) of each
>> stack, but
>> everything in between is "?????".
>>
>
> Maybe this is related to the fact that we have function descriptors on
> BE and simple function pointers on LE. You may have a look at the
> elf-decoder for ppc64 to find some more information.
Yes, indeed. With the following patch, the mixed mode option works fine on
ppc64 little endian,
but not on big endian:
Index:
jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java
===================================================================
---
jdk9-dev.orig/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java
+++
jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java
@@ -60,14 +60,15 @@ final public class LinuxPPC64CFrame exte
return null;
}
- Address nextSP = sp.getAddressAt( PPC64ThreadContext.SP * address_size +
PPC64_STACK_BIAS);
+ Address nextSP = sp.getAddressAt(0);
if (nextSP == null) {
return null;
}
- Address nextPC = sp.getAddressAt(PPC64ThreadContext.PC * address_size +
PPC64_STACK_BIAS);
+ Address nextPC = sp.getAddressAt(2 * address_size);
if (nextPC == null) {
return null;
}
+
return new LinuxPPC64CFrame(dbg, nextSP, nextPC,address_size);
}
-------------------------------------------------
I see that ppc64 fixups were made in the hotspot utilities (by you) about a
year ago
(http://cr.openjdk.java.net/~simonis/webrevs/8019929.v3/). We obviously need
something
similar in the hotspot agent native code that implements the JNI call
'lookupByAddress0'.
I hacked the build_symtab_internal() function in
hotspot/agent/src/os/linux/symtab.c and
see that the symbol "offset" we're getting is really the address of the
symbol's opd.
I'm not sure where to start to fix this, so if you have any suggestions, I'm
all ears. :-)
Thanks.
-Maynard
>
>>>
>>> Regarding your "test.java" example - how do you use it?
>>>
>>> If I just attach with jstack to the Java process which runs
>>> "test.java" I get the correct stack trace of all threads. But I think
>>> that's actual no SA-functionality but a VM-feature (the same that can
>>> be triggered by sending kill -SIGQUIT to java process).
>>>
>>> If I attach with "jstack -F" I see the problems you mentioned. First I
>>> didn't saw any frame at all which confused me but then I also saw the
>>> two cases mentioned by you. I'll need to have a closer look what
>>> happens.
>>
>> I was just running the 'test' java app and, in another session, killing it
>> with SIGSEGV.
>> To be honest, I wasn't aware of the 'jstack -F' option.
>>
>
> Another possibility I've just found out is to create a core from gdb
> with the 'generate-core-file' command. You can than still inspect the
> original program in gdb while debugging how jstack is working on the
> core file.
>
>> -Maynard
>>
>>>
>>> Regards,
>>> Volker
>>>
>>>
>>>
>>> On Fri, Nov 14, 2014 at 7:09 PM, Maynard Johnson <mayna...@us.ibm.com>
>>> wrote:
>>>> When Hotspot SA tools jmap, jstack, and jsadebugd are run against a core
>>>> file, they fail with the following runtime exception:
>>>>
>>>> OS/CPU combination linux/ppc64 not yet supported
>>>>
>>>> I will post a patch set that adds this support. The patch set consists of
>>>> the following patches:
>>>>
>>>> PATCH 1/2: Updates to non-Java files to support linux/ppc64 Hotspot SA
>>>> with core files
>>>>
>>>> PATCH 2/2: New PPC64 class files (and updates to generic files) to support
>>>> linux/ppc64 Hotspot SA with core files
>>>>
>>>> These two patches apply cleanly to a November 13 pull of the jdk9-dev
>>>> upstream sources.
>>>>
>>>> ------------
>>>> Open issues:
>>>> ------------
>>>> 1) The jstack tool does not print a stack entry for the 'main()' method
>>>> of the Java
>>>> workload (attached) under test. For example:
>>>>
>>>> (Note: Addresses and method signatures elided for brevity.)
>>>>
>>>> Thread 24358: (state = IN_JAVA, current Java SP = null
>>>> )
>>>> - java.lang.String.getChars(...) @bci=58, line=814, pc=...,
>>>> Method*=... (Compiled frame; ... imprecise)
>>>> - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled
>>>> frame)
>>>> ==> (Expect an entry for test.main() here)
>>>>
>>>> 2) The jstack tool sometimes prints what appears to be two complete
>>>> stacks for the Java workload. For example:
>>>>
>>>> Thread 24779: (state = IN_JAVA, current Java SP = null
>>>> )
>>>> - java.lang.String.getChars(...) @bci=58, line=814, pc=...,
>>>> Method*=... (Compiled frame; ... imprecise)
>>>> - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled
>>>> frame)
>>>> - test.get_my_chars(...) @bci=39, line=15, pc=..., Method*=...
>>>> (Compiled frame)
>>>> - test.run_test() @bci=92, line=34, pc=..., Method*=... (Compiled
>>>> frame)
>>>>
>>>> Again, the 'test.main' method is missing, but there's also the
>>>> anomaly of the
>>>> test.run_test' method showing up twice in the stack, implying that
>>>> it is called
>>>> by 'test.get_my_chars' at line 15. But that that is not accurate.
>>>> In fact, run_test
>>>> does call String.getChars at line 33 *and* it calls
>>>> test.get_my_chars at line 34 --
>>>> but these are totally distinct call graphs. Somehow, we are seeing
>>>> these two distinct
>>>> stacks in the core file, which seems impossible.
>>>>
>>>> ---------
>>>>
>>>> Any help offered on these two open issues would be greatly appreciated.
>>>>
>>>> -Maynard
>>>
>>
>
