Bug ID: JDK-8150135 SIGSEGV in G1CollectedHeap::is_scavengable during new nmethod creation

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 9
9Resolved

The stack trace is as follows:

Stack: [0xc63ba000,0xc643b000],  sp=0xc643939c,  free space=508k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x5287cb]  G1CollectedHeap::is_scavengable(void const*)+0x1b;;  G1CollectedHeap::is_scavengable(void const*)+0x1b
V  [libjvm.so+0x860928]  nmethod::new_nmethod(methodHandle const&, int, int, CodeOffsets*, int, DebugInformationRecorder*, Dependencies*, CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*, int)+0x158;;  nmethod::new_nmethod(methodHandle const&, int, int, CodeOffsets*, int, DebugInformationRecorder*, Dependencies*, CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*, int)+0x158
V  [libjvm.so+0x39579b]  ciEnv::register_method(ciMethod*, int, CodeOffsets*, int, CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*, bool, bool, RTMState)+0x32b;;  ciEnv::register_method(ciMethod*, int, CodeOffsets*, int, CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*, bool, bool, RTMState)+0x32b
V  [libjvm.so+0x42745b]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0x102b;;  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0x102b
V  [libjvm.so+0x36f048]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x208;;  C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x208
V  [libjvm.so+0x42d2b5]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x495;;  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x495
V  [libjvm.so+0x42e04d]  CompileBroker::compiler_thread_loop()+0x28d;;  CompileBroker::compiler_thread_loop()+0x28d
V  [libjvm.so+0x9d5a95]  compiler_thread_entry(JavaThread*, Thread*)+0x15;;  compiler_thread_entry(JavaThread*, Thread*)+0x15
V  [libjvm.so+0x9e19d4]  JavaThread::thread_main_inner()+0xf4;;  JavaThread::thread_main_inner()+0xf4
V  [libjvm.so+0x9e1b7c]  JavaThread::run()+0x16c;;  JavaThread::run()+0x16c
V  [libjvm.so+0x8895f4]  java_start(Thread*)+0xd4;;  java_start(Thread*)+0xd4

[~aharlap], thanks for verifying!
15-03-2016
I cannot reproduce issue after applying proposed by Tobias fix.
15-03-2016
JDK-8150804
15-03-2016
This bug is a duplicate of JDK-8150804. Issue show up only in product build. Easy to reproduce on host vmsqe-core2d-03.ru.oracle.com with product build Linux_x86 32 bit JDK. Just run java Bug6772689 repeatedly. I tracked down broken oop back to Compile::Process_OopMap_Node where corrupted monitor node was processed.
15-03-2016
Sounds like this could be related to JDK-8150804 where we end up with a incorrect oop for a monitor object. I will push the following fix soon: http://cr.openjdk.java.net/~thartmann/8150804/webrev.02/ This should hit an assert in debug VMs. Does the issue only show up with product builds? Are you able to reproduce this to check if above fix solves the issue?
15-03-2016
It seems like we're creating an nmethod and we have installed a broken oop. This is more likely to be compiler bug than GC bug.
15-03-2016

Duplicate :	JDK-8150804 - C2 Compilation fails with assert(_base >= OopPtr && _base <= AryPtr) failed: Not a Java pointer
Relates :	JDK-8149898 - mach5 tier-1: vm crashed intermittently in java/util/TimeZone/Bug6772689.java