SIGSEGV crash in ObjectMonitor::enter with latest Shenandoah JDK8

[Roman Kennke]

Hi Alexander,

Have you been able to make any progress with this issue?

I'm still digging. Even just having more hs_err files might help.
Getting a failure from a fastdebug build would be better, but I am not
sure this would even reproduce with fastdebug ?


Thanks,
Roman


> The object alignment part is most probably not the cause of this. The error
> log I sent you is from a QA machine which is smaller, so I reduce -Xmx
> there while keeping the rest of the options unchanged (including object
> alignment). In production (where the crash originally happened), the heap
> is set to 62g.
> 
> Regarding the fastdebug build, this will take a bit longer. Fastdebug build
> is so slow that the application can't even start in time to not be killed
> by the load balancer healthchecks:). I'll repat the experiment tomorrow.
> 
> On Mon, 4 Nov 2019 at 18:33, Aleksey Shipilev <shade at redhat.com> wrote:
> 
>> On 11/4/19 4:44 PM, Alexander Yakushev wrote:
>>> Hello again! After some time, I finally managed to reproduce the crash
>> in a non-production
>>> environment with +ShenandoahVerify. I attach the hs_err file.
>>
>> Thanks. I notice that you are running in the unusual configuration:
>>   -Xmx12g -Xms12g -XX:ObjectAlignmentInBytes=16
>>
>> Alignment to 16 bytes is not needed for the heap this small, and it just
>> wastes memory.
>>
>> We are trying to see if that could be the source of bugs too...
>>
>>> This was reproduced with a regular shenandoah-jdk8 build. Meanwhile,
>> I've built the application with
>>> fastdebug build and will try with that too if necessary.
>>
>> Yes, that would be handy. The current hs_err does not yield interesting
>> failure, it seems to be NULL
>> dereference somewhere ObjectMonitor code -- which may or may not be the GC
>> fault. Need to meditate
>> on this a little bit...
>>
>> --
>> Thanks,
>> -Aleksey
>>
>>