Closed
Bug 534349
Opened 15 years ago
Closed 13 years ago
Assertion Failure: New Context, Property Cache Enable, Concurrent GC
Categories
(Core :: JavaScript Engine, defect, P2)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: david.barbour, Unassigned)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
Build Identifier: SpiderMonkey 1.8.0rc1
SpiderMonkey emits assertion failure on PropertyCache Enable operation performed from a Garbage Collection (js_GC) while another thread is creating a context (JS_NewContext).
Problem was isolated: js_GC has a pair of steps that iterate through all contexts, first to disable property caches, then later to enable property caches. However, the set of contexts so iterated is not atomic... that is, there may be a 'new' context during when enabling property caches that was not present when disabling them.
Reproducible: Sometimes
Steps to Reproduce:
1. Pump GC Zeal to 2
2. Start one thread creating many new GC things
3. Create a new context in another thread.
4. Repeat until race-condition is encountered.
Suggest fix: in jscntxt.c, js_SetContextThread, suggest performing a JS_LOCK_GC prior to performing any actions that manipulate propertyCache or affect which thread is assigned to a given cx. This also means locking around the memset for the propertyCache (esp. since a thread might be associated with more than one context, that risks another crash).
Comment 1•15 years ago
|
||
David, could you attach your test case? (if you have one)
Severity: critical → major
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
OS: Windows XP → All
Priority: -- → P2
Hardware: x86 → All
Comment 2•15 years ago
|
||
On 1.9.1 and later this was fixed in bug 437325.
Comment 3•15 years ago
|
||
(In reply to comment #0)
> Suggest fix: in jscntxt.c, js_SetContextThread, suggest performing a JS_LOCK_GC
> prior to performing any actions that manipulate propertyCache or affect which
> thread is assigned to a given cx.
This also requires to call js_WaitForGC from inside the lock to ensure serialization against the GC.
Reporter | ||
Comment 4•15 years ago
|
||
Igor: I must assume you refer to the:
if(rt->gcThread != cx->thread)
while(rt->gcLevel > 0)
JS_AWAIT_GC_DONE(rt);
There is no 'js_WaitForGC' or any variation I can find in the 1.8 branch, but the above pattern is pervasive.
Andreas: I have no clean unit-test case that doesn't come with the whole pile of dependencies for my project. I apologize for the inconvenience.
Comment 5•15 years ago
|
||
(In reply to comment #2)
> On 1.9.1 and later this was fixed in bug 437325.
Is this fixed?
Updated•15 years ago
|
Status: NEW → RESOLVED
blocking2.0: ? → -
Closed: 15 years ago
Resolution: --- → FIXED
Updated•15 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 6•13 years ago
|
||
If this is fixed on 1.9.1+, it's as fixed as it's ever going to be.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 13 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•