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

[Daniel D. Daugherty]

On 5/30/19 1:15 AM, David Holmes wrote:
> Hi Dan,
>
> Having gone through the other RFR for JDK-8188872 I propose that this 
> issue be "fixed" purely for the test case at hand:
>
>   void os::die() {
>     if (TestUnresponsiveErrorHandler && !CreateCoredumpOnCrash) {
>       os::signal_raise(SIGKILL);
>     } else {
>       ::abort();  // dumps core (for debugging aid)
>     }
>   }

That's an option and I originally considered it, but I figured I
would be called out (even more) for spreading more uses of
TestUnresponsiveErrorHandler.

That solves the 'core' file issue for this test (and will help
the Solaris boxes from timing out due to core file creation).

What should we do about the 31 other tests that use the
'-XX:-CreateCoredumpOnCrash' option? Granted, it is entirely
possible that the other 31 tests do not have an os::die() call
in their 'normal' execution, but it is possible that some do...

Dan

P.S.
I have a side task where I'm trying to figure out what is
creating all the unexpected core files in /cores on my MBP13.
I don't know where that experiment will lead, but I suspect
that some of them are due to '-XX:-CreateCoredumpOnCrash' not
being honored...



>
> Cheers,
> David
>
> On 30/05/2019 5:29 am, Daniel D. Daugherty wrote:
>> 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
>>>
>>>
>>>
>>