RFR(XXS): 8224793: os::die() does not honor CreateCoredumpOnCrash option

[Daniel D. Daugherty]

Greetings,

I've updated the fix from calling os::exit(1) to calling
os::signal_raise(SIGKILL). Here's the updated webrevs:

Full webrev:
http://cr.openjdk.java.net/~dcubed/8224793-webrev/1-for-jdk-jdk13.full/

Incremental webrev:
http://cr.openjdk.java.net/~dcubed/8224793-webrev/1-for-jdk-jdk13.inc/

I have Mach5 Tier[1-3] testing running right now and it is looking good.
I'll follow with Mach5 Tier[456] testing. Manually running 'java' with
the options from the test in JDK-8188872 shows this snippet:

> # Problematic frame:
> # V  [libjvm.dylib+0xc06347] VMError::controlled_crash(int)+0xd5
> #
> # CreateCoredumpOnCrash turned off, no core file dumped
> #
> # An error report file with more information is saved as:
> # /work/shared/bug_hunt/jdk_jdk_exp/hs_err_pid79552.log
> Recording reporting_start_time for TestUnresponsiveErrorHandler.
> # [ timer expired, abort... ]
> Killed: 9
>
> $ echo $?
> 137

The "Killed: 9" is a _nice_ addition that shows we had an abnormal
termination. The exit_code == 137 is also way better than my
original exit_code == 1.

David, Kim and I are still hashing out whether -XX:-CreateCoredumpOnCrash
takes precedence or not.

Dan



On 5/28/19 7:37 PM, Daniel D. Daugherty wrote:
> Resending with the bug's JBS link included...
>
> Greetings,
>
> While working on another bug (JDK-8188872), I happened to notice that
> the test was generating core files even though the test is run with
> the '-XX:+CreateCoredumpOnCrash' option.
>
> After investigating, I discovered that the os::die() function does not
> honor the CreateCoredumpOnCrash option which was a surprise to me.
>
> Webrev URL: 
> http://cr.openjdk.java.net/~dcubed/8224793-webrev/0-for-jdk-jdk13/
>
> Bug: JDK-8224793 os::die() does not honor CreateCoredumpOnCrash option
>      https://bugs.openjdk.java.net/browse/JDK-8224793
>
> Testing: Mach5 Tier[1-5]
>          Included the fix in my latest round of 8153224 testing
>          on Solaris-X64 where this bug reproduces quite a bit.
>
> Thanks, in advance, for any comments, suggestions, or questions.
>
> Dan
>
>
>