Hi Roger, On Thu, Jun 1, 2017 at 3:06 PM, Roger Riggs <[email protected]> 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 <[email protected]> >> 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 >>> >>>> >>>> >
