asserts in jdk coding (outside hotspot)

Thomas Stüfe thomas.stuefe at gmail.com
Thu Jun 1 12:26:39 UTC 2017


Hi David,

On Thu, Jun 1, 2017 at 2:09 PM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi Thomas,
>
> On 1/06/2017 7:20 PM, Thomas Stüfe wrote:
>
>> Hi all,
>>
>> so, we have the hotspot asserts with all the niceties of our error
>> reporting. But these asserts are only accessible from within hotspot
>> coding.
>>
>> In the JDK, in a number of places, I see that we use the standard posix
>> assert()(
>> http://pubs.opengroup.org/onlinepubs/009695399/functions/assert.html).
>>
>> This means that when we trigger the assert, we will only get a brief
>> message on stderr and a core, but no hs_err file.
>>
>> It also means that -XX:+CreateCoredumpOnCrash is ignored, so it is not
>> possible to switch off those core dumps.
>>
>> This is unfortunate and also easy to fix. We do not even have to call into
>> the hotspot to get hotspot asserts. We could just force a NULL pointer
>> access or send ourselves a SIGILL or something. Anything which triggers
>> the
>> hotspot signal handling would be fine.
>>
>> What do you think?
>>
>
> Sending ourselves a fatal signal doesn't indicate what assertion failed.
> The error handler won't know it was an assert, just a SEGV or SIGILL
>
> ??
>
> David
>

Sure. But in many cases this still would be preferable to just a core. We'd
get a hs-err file - admittedly with a Segv instead of an assert message -
but we have a callstack and could deduce the error from there.

I am not saying that this is an ideal solution. Of course, a really good
solution may invoke the real hotspot assert or one might come up with a way
to transfer assert information (message, file, line etc) to the hotspot
error handler. E.g. store the assert message in a globally visible char
array one could resolve via dlsym to avoid having to add link dependencies.


..Thomas


>
> Kind Regards, Thomas
>>
>>


More information about the core-libs-dev mailing list