Bug ID: JDK-8248442 Kitchensink24HStress.java SIGSEGV in G1ParScanThreadState::copy_to_survivor

JDK-8248442 : Kitchensink24HStress.java SIGSEGV in G1ParScanThreadState::copy_to_survivor_space due to bad Handle

Type: Bug
Component: hotspot
Sub-Component: runtime
Affected Version: 16

Priority: P2
Status: Closed
Resolution: Duplicate
OS: linux
CPU: x86_64

Submitted: 2020-06-28
Updated: 2020-07-13
Resolved: 2020-07-13

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 16
16Resolved

Related Reports

Duplicate :	JDK-8248650 - [BACKOUT] Backout JDK-8244603 because it generates too much noise in CI
Relates :	JDK-8244603 - G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs
Relates :	JDK-8248013 - Crash occurs in java/lang/StackWalker/LocalsAndOperands.java
Relates :	JDK-8248447 - SIGSEGV in G1ScanHRForRegionClosure::scan_heap_roots
Relates :	JDK-8241804 - Dacapo24H.java SIGSEGV in G1ParScanThreadState::copy_to_survivor_space

Description

The following test failed in the JDK16 CI:

applications/kitchensink/Kitchensink24HStress.java

Here's the crashing thread's stack:

--------------- T H R E A D ---------------

Current thread (0x00007f9140000ca0): GCTaskThread "GC Thread#1" [stack: 0x00007f91490fc000,0x00007f91491fc000] [id=11455]

Stack: [0x00007f91490fc000,0x00007f91491fc000], sp=0x00007f91491f9710, free space=1013k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x685bbb] G1ParScanThreadState::copy_to_survivor_space(G1HeapRegionAttr, oopDesc*, markWord)+0x4b
V [libjvm.so+0x6a2ccc] G1ParCopyClosure<(G1Barrier)0, (G1Mark)1>::do_oop(oopDesc**)+0x15c
V [libjvm.so+0x6fda3d] HandleArea::oops_do(OopClosure*)+0x5d
V [libjvm.so+0xceb348] JavaThread::oops_do(OopClosure*, CodeBlobClosure*)+0x58
V [libjvm.so+0xcf19e7] Threads::possibly_parallel_oops_do(bool, OopClosure*, CodeBlobClosure*)+0x187
V [libjvm.so+0x6a47f3] G1RootProcessor::process_java_roots(G1RootClosures*, G1GCPhaseTimes*, unsigned int)+0x73
V [libjvm.so+0x6a53f3] G1RootProcessor::evacuate_roots(G1ParScanThreadState*, unsigned int)+0x63
V [libjvm.so+0x641a92] G1EvacuateRegionsTask::scan_roots(G1ParScanThreadState*, unsigned int)+0x22
V [libjvm.so+0x6424d9] G1EvacuateRegionsBaseTask::work(unsigned int)+0x99
V [libjvm.so+0xd8e21d] GangWorker::loop()+0x4d
V [libjvm.so+0xcf325d] Thread::call_run()+0xfd
V [libjvm.so+0xb468a7] thread_native_entry(Thread*)+0xe7


siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000901487108

Comments

This test failure mode was first spotted in the jdk-16+4-94-tier8 CI job set and there is only one sighting of this exact failure mode. This failure mode has not reproduced since Thomas pushed: JDK-8248650 [BACKOUT] Backout JDK-8244603 because it generates too much noise in CI This bug can be closed as a duplicate of JDK-8248650 if Thomas agrees.

06-07-2020

ILW = HLH = P2

30-06-2020

This bug was split off from JDK-8241804 at Stefan's request: [~dcubed] The top frame is just a GC function that will crash if an oop is broken. It's very unlikely that this is the source of the bug, and by grouping these crashes together, you run the risk of conflating the issues. It's usually better to look at the frames below, and see what the GC tries to scan. Often you find some runtime code that is broken and needs the attention: Original bug (looks like a GC issue): V [libjvm.so+0x661b2b] G1ParScanThreadState::trim_queue_partially()+0x44b V [libjvm.so+0x678357] G1ScanHRForRegionClosure::scan_heap_roots(HeapRegion*)+0x517 V [libjvm.so+0x672772] G1RemSet::scan_heap_roots(G1ParScanThreadState*, unsigned int, <snip possible CLD issue> Broken Handle (Runtime issue?): V [libjvm.so+0x6a2ccc] G1ParCopyClosure<(G1Barrier)0, (G1Mark)1>::do_oop(oopDesc**)+0x15c V [libjvm.so+0x6fda3d] HandleArea::oops_do(OopClosure*)+0x5d V [libjvm.so+0xceb348] JavaThread::oops_do(OopClosure*, CodeBlobClosure*)+0x58 V [libjvm.so+0xcf19e7] Threads::possibly_parallel_oops_do(bool, OopClosure*, CodeBlobClosure*)+0x187 V [libjvm.so+0x6a47f3] G1RootProcessor::process_java_roots(G1RootClosures*, G1GCPhaseTimes*, unsigned int)+0x73 I think these kind of issues need to split up into separate bugs, so that they are all investigated separately.

28-06-2020