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

Kim Barrett kim.barrett at oracle.com
Wed May 29 17:19:17 UTC 2019


> On May 29, 2019, at 10:27 AM, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
> On 5/28/19 9:03 PM, Kim Barrett wrote:
>> And looking at this some more, I think I agree with David's comment in
>> the CR, that os::die *should* always dump core.  It gets called when
>> things have gone horribly wrong, and a core dump might be the only way
>> to understand what went wrong.
> 
> I understand where you and David are coming from. […]
> 
> To run a test with '-XX:-CreateCoredumpOnCrash' and then see a core
> file in the execution directory violates the principle of least
> astonishment. From the test author's POV, they did what they are
> supposed to do (passing the '-XX:-CreateCoredumpOnCrash' option)
> and the result is unexpected.

The position that David and I are taking is that the unexpected core
dump is not a problem, and is indeed a good thing, because the test
apparently ran off into the weeds.

>> Maybe there are paths to os::die that ought to be calling os::abort
>> instead?
> 
> Maybe, but not really the problem that I'm trying to solve today. :-)

That presumes that the problem is the behavior of os::die rather than
who is calling it.  David and I are suggesting the behavior of os::die
is fine, and the reason for the unexpected core dump from the test is
that os::die is being called when (perhaps) it shouldn't be.  Or maybe
the test really is going off into the weeds and a call to os::die is
appropriate and the core dump might contain useful information.

>> I think os::abort probably should not be calling ::exit either, but
>> should be raising SIGKILL if no core dump is requested.  os::exit is
>> the path to exit functions and the like.
> 
> Agreed (or maybe not). If I'm in os::abort() and I call '::exit()',
> am I calling 'os::exit()' or am I calling libc's exit()? I thought
> I was calling libc's exit(), but I could be wrong…

::exit() is libc's exit(), which calls atexit handlers.

Also, ::_exit() or _Exit() (the latter is in <stdlib.h>) might be
alternatives to using SIGKILL.

>> It's unfortunate that the Linux version of os::abort needs to do
>> something special for DumpPrivateMappingsInCore; without that, we
>> could have a merged posix version of os::abort.
> 
> I think that's a fairly recent addition to the Linux version of
> os::abort(). It could probably be handled by a posix version of
> os::abort() that calls a PD version of os::abort() as needed or
> something like that.
> 
> Again, not the problem that I'm trying to solve today.

Agreed.



More information about the hotspot-runtime-dev mailing list