RFR(s): 8065895: Synchronous signals during error reporting may terminate or hang VM process

David Holmes david.holmes at oracle.com
Thu Jan 29 07:47:33 UTC 2015

Hi Thomas,

Sorry for the delay in getting back to this. Looks good - only a few typos:


+ // 15 - SIGILL

should be SIGFPE.


+ // Note that in the hotspot

Delete 'the'.

+ // hang or be ended immediately if secondary errors happend during error




On 26/01/2015 8:23 PM, Thomas Stüfe wrote:
> Anyone? I would really like to close this issue.
> Kind Regards,
> Thomas Stüfe
> On Wed, Jan 21, 2015 at 10:39 AM, Thomas Stüfe <thomas.stuefe at gmail.com
> <mailto:thomas.stuefe at gmail.com>> wrote:
>     Hi all,
>     I would like to take up discussion about this issue again.
>     As a reminder, here the bug report:
>     https://bugs.openjdk.java.net/browse/JDK-8065895
>     And here a new version of my patch:
>     http://cr.openjdk.java.net/~stuefe/webrevs/8065895/webrev.05/webrev/
>     As far as I remember the discussion, the issue itself was understood
>     and the fix itself met with approval (I think), but the point of
>     contention was the code I added to reproduce the error for
>     regression tests.
>     In order to reproduce the error, I need two different synchronous
>     signals to happen, one in normal code, one in the error handler
>     which writes the hs-err file. Originally I choose SIGSEGV and
>     SIGILL. I added functions to generate (true, real) SIGSEGVs and
>     SIGILLs. But nobody liked my generate-sigill function, therefore I
>     changed the code to generate a SIGFPE instead. For the test, it does
>     not matter which signals are generated as long as they are
>     synchronous (so, one of SEGV,ILL,BUS,FPE).
>     In order to check that the fix works, one can do:
>     java -XX:ErrorHandlerTest=15 -XX:TestCrashInErrorHandler=14
>     The VM will first crash with a SIGSEGV, enter error handling, crash
>     again with a different synchronous signal (FPE, in this case). An
>     unfixed VM will die immediately and we get a torn hs-err file. A
>     fixed VM will show the "error occurred during error handling" string
>     and continue with the error reporting.
>     Kind Regards,
>     Thomas Stüfe
>     On Mon, Dec 8, 2014 at 11:37 AM, Thomas Stüfe
>     <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com>> wrote:
>         Hi David, Dean,
>         On Fri, Dec 5, 2014 at 8:05 AM, David Holmes
>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>             On 3/12/2014 8:47 PM, Thomas Stüfe wrote:
>                 Hi Dean,
>                 I dont understand. Such a function does not exist, does
>                 it? So I would
>                 have to write it:
>                 Do you mean generating and using a StubRoutine which
>                 would SIGILL? I did
>                 not do this because I wanted to be able to generate
>                 SIGILL also in
>                 initialization code, where StubRoutines may not yet be
>                 generated. This
>                 point may may be arguable, but as this function is used
>                 to test error
>                 handling, it may be interesting to test it for
>                 half-initialized VMs too.
>                 Otherwise I would implement the CPU specific
>                 generate_illegal_instruction_____sequence() probably the
>                 same way as I do
>                 now the crash_with_sigill() function. That would mean a
>                 bit of more code
>                 duplication because:
>                 - Either I use the method I use now (reserve_memory and
>                 copy the
>                 instructions to the reserved page)
>                 - Or I use inline assembly - which probably does not
>                 work across
>                 multiple OSs, so for CPUs which span various OSs I would
>                 have to add one
>                 function per os_cpu combination, not just per cpu.
>             I don't think there is any OS dependency with inline
>             assembly - only compiler. And I am also concerned that
>             writing code to an executable page will also enter the realm
>             of "self-modifying code" and all the jumping through hoops
>             that entails. That aspect hadn't occurred to me till Dean
>             raised it. I'm forming the view that triggering a SIGILL is
>             more effort than it is worth for a secondary testing function.
>         Well, the code is used and works in our VM since some years on a
>         number of CPUs, so the problem with the flushing do not occur at
>         least in our cases. But I agree with you, and this seems to be a
>         point of contention and it is really too unimportant to stop the
>         whole patch.
>         The whole point of using SIGILL was to have another unblockable
>         signal besides SIGSEGV to occur naturally (without raising) to
>         be able to demonstrate the bug before fixing it. I will now
>         attempt to change the patch to use either SIGFPE or SIGBUS as a
>         secondary signal. Maybe generating those signals with pure C/C++
>         is easier. If that does not work out, I will see what I can do
>         with raise().
>         Thanks and Kind regards, Thomas

More information about the hotspot-runtime-dev mailing list