Debugging segmentation faults in the JVM on linux-powerpc
John Paul Adrian Glaubitz
glaubitz at physik.fu-berlin.de
Fri Jun 9 15:02:26 UTC 2017
On 06/09/2017 04:30 PM, Gustavo Romero wrote:
> You can attach gdb when the error occurs passing to the JVM:
> -XX:OnError="gdb %p"
> -XX:OnOutOfMemoryError="gdb %p"
Aha, that's a very useful feature. Thanks for the tip.
> Another thing is that the JVM will use SIGSEGV for some state transitions, hence
> in gdb I usually let SIGSEGV be passed to the JVM:
> (gdb) handle SIGSEGV pass noprint nostop
But it does not mean the segmentation faults I have observed are actually
intentional, are they?
What confuses me most is that the JVM segfaults during the build but
bails out with the out-of-memory error when I manually run any of
the commands after the failed build. It almost looks like I forgot
to set some environment variables.
> On PPC64 (not sure what's the current state on PPC32) we can also have SIGTRAP
> for state transitions and I had some trouble in the past debugging with
> -XX:+UseSIGTRAP enabled (basically gdb halts on some specific thread types that
> generates such a type of signal), so I also usually ask to the JVM to not use
> SIGTRAP and use SIGILL instead, enabling the passthrough of SIGILL:
> (gdb) handle SIGILL pass noprint nostop
> and calling the JVM with "-XX:-UseSIGTRAP".
Good to know. I would have been confused by that behavior for sure.
> Starting the JVM from gdb it's also fine given that you handle the signals,
> otherwise all can go well until init_globals() but beyond that, after some
> threads are created, the debugging can halt for no apparently reason.
What's the best way to actually start the JVM from gdb? Do I just
load "java" into gdb and run it with the suggested parameters?
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
More information about the hotspot-dev