jdk11 SIGSEGV in G1CMTask::make_reference_grey

[Vitaly Davidovich]

Hi Stefan,

On Wed, May 11, 2022 at 8:24 AM Stefan Karlsson <stefan.karlsson at oracle.com>
wrote:

> 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.
>
Ah, thanks for sharing that!

>
>
> 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.
>
Ouch, that must’ve been “fun” to debug :).

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
>     }
>
<thumbs up>

>
>
> StefanK
>
>
> Thanks!
>
>
> --
Sent from my phone