JDK-8055420 : SIGSEGV in CompileQueue::delete_all during compiler's shutdown
- Type: Bug
- Component: hotspot
- Sub-Component: compiler
- Affected Version: 8u40
- Priority: P2
- Status: Closed
- Resolution: Duplicate
- OS: generic
- CPU: generic
- Submitted: 2014-08-19
- Updated: 2023-07-21
- Resolved: 2023-07-21
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.
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 8 |
|---|
8Resolved  |
Related Reports
|
Duplicate :
|
Description
Compiler's shutdown may be ended up by SIGSEGV in CompileQueue::delete_all: Current thread (0x00000001011f7000): JavaThread "C2 CompilerThread11" daemon [_thread_in_vm, id=63, stack(0xffffffff20e00000,0xffffffff20f00000)] siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0xbabababababaa001 Registers: G1=0x00000000000c39e8 G2=0x00000000000c3800 G3=0x0000000000108400 G4=0x0000000000000bc0 G5=0x0000000000000800 G6=0x0000000000000000 G7=0xffffffff7a10f200 Y=0x0000000000000000 O0=0x0000000000000000 O1=0x0000000000000000 O2=0x0000000000000000 O3=0x0000000000000000 O4=0x0000000000000000 O5=0x0000000000000000 O6=0xffffffff20efea41 O7=0xffffffff7d76549c L0=0xffffffff7e433ec8 L1=0xffffffff7e03e341 L2=0x0000000000001020 L3=0xbababababababaaa L4=0x0000000000005a90 L5=0xffffffffffcdd011 L6=0x0000000000005800 L7=0xffffffff7e03ee68 I0=0xbabababababababa I1=0xbababababababa9a I2=0x0000000000bfbe94 I3=0x0000000000322c00 I4=0xffffffff7a10f200 I5=0xffffffff7e361330 I6=0xffffffff20efeb01 I7=0xffffffff7d765ed4 PC=0xffffffff7d765518 nPC=0xffffffff7d76551c Stack: [0xffffffff20e00000,0xffffffff20f00000], sp=0xffffffff20eff240, free space=1020k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xf65518] void verify_memory(void*)+0x80 V [libjvm.so+0xf65edc] void os::free(void*,unsigned short)+0x94 V [libjvm.so+0x6c3338] void CHeapObj<(unsigned short)1536>::operator delete(void*)+0x48 V [libjvm.so+0x6badc4] void CompileQueue::delete_all()+0x6c V [libjvm.so+0x6be124] void CompileBroker::shutdown_compiler_runtime(AbstractCompiler*,CompilerThread*)+0x11c V [libjvm.so+0x6bdf88] bool CompileBroker::init_compiler_runtime()+0x1c0 V [libjvm.so+0x6be2e4] void CompileBroker::compiler_thread_loop()+0x174 V [libjvm.so+0x11fa3f0] void JavaThread::thread_main_inner()+0x268 V [libjvm.so+0x11fa114] void JavaThread::run()+0x3f4 V [libjvm.so+0xf71878] java_start+0x258 C [libc.so.1+0xd8560] _lwp_start+0x8 Crash happened when we tried to load from [i1 = 0xbababababababa9a]. Issue was found during the PIT for jdk8u40-b02. It could be reproduced with fastdebug builds only and only on Solaris (both sparc and x64). I was not able to reproduce it with 8u40-b01 and latest promoted jdk9 build. See comments for more details.
Comments
|