Misbehaving exit status from Hotspot

Charles Oliver Nutter headius at headius.com
Tue Jun 26 19:05:07 UTC 2018

(mods: previous version of this was sent without subscription complete;

Hello all!

I've been struggling to fix some signal-handling issues in JRuby and I've
come to the determination that Hotspot is not being a good actor as far as
signals and exit statuses go.

I've put together some C and Java code to demonstrate the problem. I could
have flaws in my understanding of signal handling and exit statuses.

The test program just spawns a given command, waits for termination, and
uses the wait(2) W macros to parse out the process exit states.

"loop.c" just loops.
"loop2.c" has the loop but also installs a TERM signal handler, closer in
behavior to shutdown hooks in Ruby and JVM.
"Loop.java" just loops.

The first two produce the expected results...

$ ./sigtest `pwd`/loop
pid: 22130
status: 15
exited: 0, stop signal: 0, term signal: 15, exit status: 0

$ ./sigtest `pwd`/loop2
term received
pid: 22173
status: 15
exited: 0, stop signal: 0, term signal: 15, exit status: 0

Java produces nonsense results...

$ ./sigtest `which java` Loop
pid: 22136
status: 36608
exited: 1, stop signal: 143, term signal: 0, exit status: 143

I have tried various combinations of using the sun.misc.Signal stuff, doing
a native downcall to raise(3), and so on...but nothing helps, probably
because the Hotspot's own TERM handler is swallowing or otherwise
mutilating the exit status.

We do get bug reports about JRuby's exit statuses not making any sense. I
assumed it was our fault until this week.


- Charlie

More information about the hotspot-runtime-dev mailing list