Closed Bug 832217 Opened 11 years ago Closed 11 years ago

assertion failure [@ js::RegExpCompartment::~RegExpCompartment] during shutdown in xpcshell\tests\services\sync\tests\unit\test_resource.js

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla21

People

(Reporter: dbaron, Unassigned)

Details

(Keywords: assertion, intermittent-failure)

Attachments

(1 file)

Construct RegExpShared in the same compartment as the statics.
10.05 KB, patch
billm
: review+
Details | Diff | Splinter Review 
https://tbpl.mozilla.org/php/getParsedLog.php?id=18919007&tree=Mozilla-Inbound
Rev3 WINNT 5.1 mozilla-inbound debug test xpcshell on 2013-01-17 23:32:23 PST for push 03fb2a777aec
slave: talos-r3-xp-052

hit this failure:

TEST-UNEXPECTED-FAIL | c:\talos-slave\test\build\xpcshell\tests\services\sync\tests\unit\test_resource.js | test failed (with xpcshell return code: -2147483645), see following log:

Assertion failure: shared->activeUseCount == 0, at e:/builds/moz2_slave/m-in-w32-dbg/build/js/src/vm/RegExpObject.cpp:657


Crash reason:  EXCEPTION_BREAKPOINT
Crash address: 0x2dedb95

Thread 0 (crashed)
 0  mozjs.dll!js::RegExpCompartment::~RegExpCompartment() [RegExpObject.cpp:03fb2a777aec : 657 + 0x36]
    eip = 0x02dedb95   esp = 0x0012fb10   ebp = 0x0012fb38   ebx = 0x00000000
    esi = 0x10261440   edi = 0x04b18cc0   eax = 0x00000000   ecx = 0x30ca5c70
    edx = 0x10361f48   efl = 0x00000212
    Found by: given as instruction pointer in context
 1  mozjs.dll!JSCompartment::~JSCompartment() [jscompartment.cpp:03fb2a777aec : 109 + 0xd5]
    eip = 0x02e7a5c7   esp = 0x0012fb40   ebp = 0x0012fb74
    Found by: call frame info
 2  mozjs.dll!SweepCompartments [jsgc.cpp:03fb2a777aec : 2491 + 0x6]
    eip = 0x02ed178f   esp = 0x0012fb50   ebp = 0x0012fb74
    Found by: call frame info
 3  mozjs.dll!EndSweepPhase [jsgc.cpp:03fb2a777aec : 3793 + 0x9]
    eip = 0x02eda451   esp = 0x0012fb7c   ebp = 0x0012fc28
    Found by: call frame info
 4  mozjs.dll!IncrementalCollectSlice [jsgc.cpp:03fb2a777aec : 4137 + 0x14]
    eip = 0x02edb5c1   esp = 0x0012fc30   ebp = 0x0012fc7c
    Found by: call frame info
 5  mozjs.dll!GCCycle [jsgc.cpp:03fb2a777aec : 4260 + 0x16]
    eip = 0x02edc52e   esp = 0x0012fc84   ebp = 0x0012fcc0
    Found by: call frame info
 6  mozjs.dll!Collect [jsgc.cpp:03fb2a777aec : 4378 + 0x20]
    eip = 0x02edca1e   esp = 0x0012fcc8   ebp = 0x0012fd34
    Found by: call frame info
 7  mozjs.dll!js::GC(JSRuntime *,js::JSGCInvocationKind,js::gcreason::Reason) [jsgc.cpp:03fb2a777aec : 4401 + 0x16]
    eip = 0x02edcccf   esp = 0x0012fd3c   ebp = 0x0012fd54
    Found by: call frame info
 8  mozjs.dll!js::DestroyContext(JSContext *,js::DestroyContextMode) [jscntxt.cpp:03fb2a777aec : 415 + 0x9]
    eip = 0x02e6cd30   esp = 0x0012fd5c   ebp = 0x0012fdac
    Found by: call frame info
 9  mozjs.dll!JS_DestroyContextNoGC(JSContext *) [jsapi.cpp:03fb2a777aec : 1262 + 0xa]
    eip = 0x02dfd1de   esp = 0x0012fdb4   ebp = 0x0012fdbc
    Found by: call frame info
10  xul.dll!XPCJSRuntime::~XPCJSRuntime() [XPCJSRuntime.cpp:03fb2a777aec : 1190 + 0x6]
    eip = 0x01217663   esp = 0x0012fdc4   ebp = 0x0012fde8
    Found by: call frame info
11  xul.dll!nsXPConnect::~nsXPConnect() [nsXPConnect.cpp:03fb2a777aec : 126 + 0xd]
    eip = 0x011e729b   esp = 0x0012fdd8   ebp = 0x0012fde8
    Found by: call frame info
12  xul.dll!nsXPConnect::`vector deleting destructor'(unsigned int) + 0xa
I have no workable theory for why this existed for a day on WinXP, then 10 days later has exploded on 10.8. I thought today's must be a fresh regression, but I now think my retriggers backward are just producing lots of runs and lots of failures. Maybe it'll go away again.
Most likely a duplicate of Bug 832197.
RegExpShared cannot be used by the RegExpStatics, because the two objects may be in separate compartments, and compartment collection order is not well-defined. Instead, it is sufficient to remember the information necessary to reconstruct a RegExpShared in the current compartment. This also has the benefit of being much simpler.

As well as (most likely) resolving this frequent crash on TBPL, this patch also fixes Bug 832197 and permits Bug 829758 to re-land.
Attachment #708840 - Flags: review?(dvander)
Comment on attachment 708840 [details] [diff] [review]
Construct RegExpShared in the same compartment as the statics.

Flipping review to Bill since I'll probably miss any GC subtleties.
Attachment #708840 - Flags: review?(dvander) → review?(wmccloskey)
Attachment #708840 - Flags: review?(wmccloskey) → review+
Backed out for mysterious compilation failures:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7271e80ac418

I can't reproduce the failure locally.
The linker error seems like it's almost certainly due to the "inline" here:
https://hg.mozilla.org/integration/mozilla-inbound/file/d26c537bd315/js/src/vm/RegExpObject.cpp#l683
on the get() method that your patch introduces a new caller of.  The "inline" causes the method to be emitted inline in the following method but not emitted on its own.
(In reply to Sean Stangl from comment #69)
> Backed out for mysterious compilation failures:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/7271e80ac418
> 
> I can't reproduce the failure locally.

The incorrect Bug # was entered in the commit message for the backout.
https://hg.mozilla.org/mozilla-central/rev/d26c537bd315
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
reopening since the backout also landed (but had the wrong bug number)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
https://hg.mozilla.org/mozilla-central/rev/c36bac9f8962
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: