JDK-8152695 : SEGV in g1_mark_as_young
- Type: Bug
- Component: hotspot
- Sub-Component: gc
- Affected Version: 9
- Priority: P4
- Status: Closed
- Resolution: Duplicate
- OS: linux
- CPU: x86
- Submitted: 2016-03-24
- Updated: 2016-06-20
- Resolved: 2016-06-20
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 9 |
|---|
9Resolved  |
Related Reports
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
Description
While trying to reproduce JDK-8151256, this failure occurred a couple of times in about 50k runs. A SEGV occurs in memset when called from G1SATBCardTableModRefBS::g1_mark_as_young . It looks like the address range passed to g1_mark_as_young from dirty_young_block is valid.
#20 <signal handler called>
#21 0x00007fb37d5ea886 in __memset_sse2 () from /lib64/libc.so.6
#22 0x00007fb37c9b9370 in dirty_young_block (word_size=2697, start=0xff900000, this=0x7fb374025e30)
at /scratch/workspace/9-2-build-linux-amd64-phase2/jdk9/4520/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:134
#23 attempt_allocation (gclocker_retry_count_ret=0x7fb21dd4c70c, gc_count_before_ret=0x7fb21dd4c708, word_size=2697, this=0x7fb374025e30)
at /scratch/workspace/9-2-build-linux-amd64-phase2/jdk9/4520/hotspot/src/share/vm/gc/g1/g1CollectedHeap.cpp:906
#24 G1CollectedHeap::allocate_new_tlab (this=0x7fb374025e30, word_size=2697)
at /scratch/workspace/9-2-build-linux-amd64-phase2/jdk9/4520/hotspot/src/share/vm/gc/g1/g1CollectedHeap.cpp:517
#25 0x00007fb37c882783 in CollectedHeap::allocate_from_tlab_slow (klass=..., klass@entry=..., thread=thread@entry=0x7fb214114000, size=size@entry=3)
at /scratch/workspace/9-2-build-linux-amd64-phase2/jdk9/4520/hotspot/src/share/vm/gc/shared/collectedHeap.cpp:301
It may be that all of these problems running HeapRetentionTest with +ResourceManagement are due to the same underlying synch problem (or 2).
One difference between these and the other reports is that these were run with the MainWrapper that the test system uses, rather than directly. The original failure (in 8151256) has finally just occurred once running this way.
Note, this is with build 9-ea+107-2016-02-24-205307.javare.4520, thus about a month old.
Comments
|