asserts in jdk coding (outside hotspot)
Thomas Stüfe
thomas.stuefe at gmail.com
Thu Jun 1 13:27:03 UTC 2017
Hi Roger,
On Thu, Jun 1, 2017 at 3:06 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> Hi,
>
> Is there a clean way for hotspot to export the assert mechanism so it can
> be called from
> the C based native JDK libraries?
>
> Thanks, Roger
>
>
It would be no problem to export a C stub which calls the error handler.
And maybe wrap it with a macro which evolves to nothing in NDEBUG builds.
The real problem is that this would mean you would have to link to the
hotspot in a number of places, and that is very inconvenient. We (SAP)
actually do this a lot, because we redirect a lot of functionality from the
JDK into the hotspot (e.g. tracing or malloc tracking). But this is always
a pain, you have to maintain make files and add -Ljvm to a number of
places, and you create new dependencies.
Hence my "lets just crash" idea David disliked :)
Thomas
>
>
> On 6/1/2017 8:26 AM, Thomas Stüfe wrote:
>
>> 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