jdk11 SIGSEGV in G1CMTask::make_reference_grey

Stefan Karlsson stefan.karlsson at oracle.com
Wed May 11 12:24:23 UTC 2022


Hi Vitaly,

A comment about the SI_KERNEL observation:

On 2022-05-10 15:34, Vitaly Davidovich wrote:
...
> RAX=0x0101010101010164 is an unknown value
....
> RAX contents in the register output of the report looks like an interesting
> pattern, but doesn't appear to be a valid address of anything yet the
> instruction is using it as the base of a load.  Also, si_addr in the
> siginfo claims the faulting address is actually NULL.  Not quite sure what
> to make of that yet.

We encountered the same SI_KERNEL / si_addr == 0x0 crashes while working 
on ZGC. What I learned was that if you try to dereference a pointer with 
high-order bits set (making the address larger than TASK_SIZE), then 
you'll get these crashes where si_addr doesn't tell you what the failing 
address was.

Side note: For us, it resulted in weird behaviors when the signal 
handler treated these SIGSEGVs as implicit NULL pointer exceptions, and 
we later crashed for secondary reasons. This does seem to apply to your 
situation, but I changed the signal handler code and left a comment 
about this. See PosixSignals::pd_hotspot_signal_handler in:

https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp

     if (sig == SIGSEGV && info->si_addr == 0 && info->si_code == 
SI_KERNEL) {
#ifndef AMD64
...
#else
       // An irrecoverable SI_KERNEL SIGSEGV has occurred.
       // It's likely caused by dereferencing an address larger than 
TASK_SIZE.
       return false;
#endif
     }

StefanK

>
> Thanks!



More information about the hotspot-gc-dev mailing list