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