United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6899058 G1: Internal error in ptrQueue.cpp:201 in nightly tests
6899058 : G1: Internal error in ptrQueue.cpp:201 in nightly tests

Details
Type:
Bug
Submit Date:
2009-11-06
Status:
Resolved
Updated Date:
2010-04-06
Project Name:
JDK
Resolved Date:
2010-02-08
Component:
hotspot
OS:
generic
Sub-Component:
gc
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
hs17

Related Reports
Backport:
JDK-2189881 - G1: Internal error in ptrQueue.cpp:201 in nightly tests
Relates:
JDK-6915005 - G1: Hang in PtrQueueSet::completed_buffers_list_length with gcl001
Relates:
JDK-6902115 - G1:assert(ignore_max_completed||thread->is_Java_thread()||SafepointSynchronize::is_at_safepoint())
Relates:
JDK-6888898 - CMS: ReduceInitialCardMarks unsafe in the presence of cms precleaning
Relates:
JDK-6896647 - card marks can be deferred too long

Sub Tasks

Description
The following nightly test:

nsk/stress/jni/gclocker/gcl001

is failing on linux_amd64.

The result directory (including hs_err file) can be found at:

http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2009-11-03/G1_GC_Baseline/vm/linux-amd64/server/mixed/linux-amd64_server_mixed_nsk.stress.testlist/ResultDir/gcl001//hs_err_pid7207.log

The link to the failure (giving machine details etc) can ve found at:

http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2009-11-03/G1_GC_Baseline/vm/linux-amd64/server/mixed/linux-amd64_server_mixed_nsk.stress.testlist/analysis.html
gc/gctests/StringGC

Comments
EVALUATION

This CR is now considered to have been caused as a result of a regression
introduced in 6888898 which affects all collectors, not just G1.
See 6896647 where that regression is being fixed.
2009-12-16 
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/fa357420e7d2
2009-11-25 
SUGGESTED FIX

The fix is to remove elements from the completed update buffer queue under control of the same lock using in the code that adds them. This means that we need only one (locking) version of get_completed_buffer.
2009-11-20 
EVALUATION

Race on the dirty card queue completed buffer list between worker thread(s) performing a flush of a deferred store barrier (enqueueing a newly completed buffer) and worker thread(s) in the RSet updating code claiming completed buffers.
2009-11-07


Hardware and Software, Engineered to Work Together