Debugging segmentation faults in the JVM on linux-powerpc

John Paul Adrian Glaubitz glaubitz at
Fri Jun 9 15:02:26 UTC 2017

Hi Gustavo!

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
`. `'   Freie Universitaet Berlin - glaubitz at
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

More information about the hotspot-dev mailing list