610941 - Assertion failure: compartment mismatched [@ jscntxtinlines.h:541]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

While testing if Blake's patch on bug 609139 has been fixed bug 609781, I get the below assertion and the browser crashes right after. I have used this debug tinderbox build:

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-macosx-debug/1289368601/ 

Assertion which shows up when running the Mozmill tests under testSearch:

--DOMWINDOW == 22 (0x2d7213d0) [serial = 30] [outer = 0x0] [url = chrome://browser/content/search/engineManager.xul]
*** Compartment mismatch 0x389d400 vs. 0x2115e200
Assertion failure: compartment mismatched, at /builds/moz2_slave/mozilla-central-macosx-debug/build/js/src/jscntxtinlines.h:541

Right before a couple of those assertions appeared, but not sure if those are related:

###!!! ASSERTION: This is unsafe! Fix the caller!: 'Error', file /builds/moz2_slave/mozilla-central-macosx-debug/build/content/events/src/nsEventDispatcher.cpp, line 514

Not such a really helpful crash report:
http://crash-stats.mozilla.com/report/index/bp-e664c549-a204-44d6-a965-b99d12101109

Comment 1

[Boris Zbarsky [:bzbarsky]]

I hit this while following the STR in bug 610973.

Comment 2

[Boris Zbarsky [:bzbarsky]]

At least on the 3rd or 4th click on the button.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Stack to the assert:

#0  0x044a3100 in JS_Assert (s=0x45f4974 "compartment mismatched", file=0x45f41f0 "/Users/bzbarsky/mozilla/vanilla/mozilla/js/src/jscntxtinlines.h", ln=541) at /Users/bzbarsky/mozilla/vanilla/mozilla/js/src/jsutil.cpp:80
#1  0x04364247 in js::CompartmentChecker::fail (c1=0x1703c800, c2=0x5dec000) at jscntxtinlines.h:541
#2  0x0432e152 in js::CompartmentChecker::check (this=0xbfffc028, c=0x5dec000) at jscntxtinlines.h:549
#3  0x0432e17a in js::CompartmentChecker::check (this=0xbfffc028, obj=0x677c0e0) at jscntxtinlines.h:557
#4  0x0436430f in js::assertSameCompartment<JSObject*, jsid, js::Value> (cx=0x2429e0f0, t1=0x677c0e0, t2={asBits = 108835936}, t3={data = {asBits = 18446462607322775552, s = {payload = {i32 = 0, u32 = 0, boo = 0, str = 0x0, obj = 0x0, ptr = 0x0, why = JS_ARRAY_HOLE}, tag = JSVAL_TAG_UNDEFINED}, asDouble = -nan(0xf000200000000), asPtr = 0x0}}) at jscntxtinlines.h:643
#5  0x0440b2e7 in js::CallJSPropertyOp (cx=0x2429e0f0, op=0x4477b53 <str_getProperty(JSContext*, JSObject*, jsid, js::Value*)>, obj=0x677c0e0, id={asBits = 108835936}, vp=0xbfffc260) at jscntxtinlines.h:727
#6  0x044001ff in js_GetPropertyHelperWithShapeInline (cx=0x2429e0f0, obj=0x677c0e0, receiver=0x677c0e0, id={asBits = 108835936}, getHow=0, vp=0xbfffc260, shapeOut=0xbfffc14c, holderOut=0xbfffc148) at /Users/bzbarsky/mozilla/vanilla/mozilla/js/src/jsobj.cpp:4964
#7  0x044005e3 in js_GetPropertyHelperInline (cx=0x2429e0f0, obj=0x677c0e0, receiver=0x677c0e0, id={asBits = 108835936}, getHow=0, vp=0xbfffc260) at /Users/bzbarsky/mozilla/vanilla/mozilla/js/src/jsobj.cpp:5058
#8  0x04400615 in js_GetProperty (cx=0x2429e0f0, obj=0x677c0e0, receiver=0x677c0e0, id={asBits = 108835936}, vp=0xbfffc260) at /Users/bzbarsky/mozilla/vanilla/mozilla/js/src/jsobj.cpp:5071
#9  0x0432a2ae in JSObject::getProperty (this=0x677c0e0, cx=0x2429e0f0, receiver=0x677c0e0, id={asBits = 108835936}, vp=0xbfffc260) at jsobj.h:1075
#10 0x0448e27d in JSObject::getProperty (this=0x677c0e0, cx=0x2429e0f0, id={asBits = 108835936}, vp=0xbfffc260) at jsobj.h:1079
#11 0x04593f33 in js::mjit::ic::GetProp (f=@0xbfffc2a0, pic=0x5546370) at /Users/bzbarsky/mozilla/vanilla/mozilla/js/src/methodjit/PolyIC.cpp:1655
#12 0x21cfaeb2 in ?? ()
#13 0x04541423 in js::mjit::EnterMethodJIT (cx=0x2429e0f0, fp=0x17800038, code=0x21cfaa44, stackLimit=0x1788ca68) at /Users/bzbarsky/mozilla/vanilla/mozilla/js/src/methodjit/MethodJIT.cpp:739
#14 0x0454153a in CheckStackAndEnterMethodJIT (cx=0x2429e0f0, fp=0x17800038, code=0x21cfaa44) at /Users/bzbarsky/mozilla/vanilla/mozilla/js/src/methodjit/MethodJIT.cpp:764
#15 0x04541662 in js::mjit::JaegerShot (cx=0x2429e0f0) at /Users/bzbarsky/mozilla/vanilla/mozilla/js/src/methodjit/MethodJIT.cpp:781
#16 0x043e041a in js::RunScript (cx=0x2429e0f0, script=0x21ee4450, fp=0x17800038) at jsinterp.cpp:662
#17 0x043e1203 in js::Invoke (cx=0x2429e0f0, argsRef=@0xbfffc494, flags=0) at jsinterp.cpp:768
#18 0x043e18f8 in js::ExternalInvoke (cx=0x2429e0f0, thisv=@0xbfffc4f8, fval=@0xbfffc538, argc=1, argv=0x279a1e10, rval=0xbfffc600) at jsinterp.cpp:881
#19 0x04310e74 in js::ExternalInvoke (cx=0x2429e0f0, obj=0x24a12b60, fval=@0xbfffc538, argc=1, argv=0x279a1e10, rval=0xbfffc600) at jsinterp.h:954
#20 0x04310fcc in JS_CallFunctionValue (cx=0x2429e0f0, obj=0x24a12b60, fval={asBits = 18446462629412154264, s = {payload = {i32 = 614542232, u32 = 614542232, boo = 614542232, str = 0x24a12b98, obj = 0x24a12b98, ptr = 0x24a12b98, why = 614542232}, tag = JSVAL_TAG_OBJECT}, asDouble = -nan(0xf000724a12b98), asPtr = 0x24a12b98}, argc=1, argv=0x279a1e10, rval=0xbfffc600) at /Users/bzbarsky/mozilla/vanilla/mozilla/js/src/jsapi.cpp:4898
#21 0x0096b57a in nsJSContext::CallEventHandler (this=0x2429dbe0, aTarget=0x24404390, aScope=0x24a100a0, aHandler=0x24a12b98, aargv=0x2472e270, arv=0xbfffc7d4) at /Users/bzbarsky/mozilla/vanilla/mozilla/dom/base/nsJSEnvironment.cpp:2171

Comment 4

[Boris Zbarsky [:bzbarsky]]

So when I hit this, in frame 2 we have:

(gdb) p c->principals
$5 = (JSPrincipals *) 0x0
(gdb) p context->runtime->defaultCompartment->principals
$7 = (JSPrincipals *) 0x0
(gdb) p compartment->principals->codebase
$9 = 0x2781e118 "http://getfirebug.com/tests/issues/3632/issue3632.html"

The |obj| in frame 3, which is the thing that has a compartment with null principals that's not the default compartment (obj->compartment() == c) is String.prototype (or at least something of class String, which has a proto of class Object).  Looks like c->scripts is an empty list, if that matters.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Henrik, does mozmill use jsd?  I'm seeing us creating all sorts of objects on a compartment with null principals from _newJSDContext, and that's the compartment |c| is when I hit the assert.

Comment 6

[Boris Zbarsky [:bzbarsky]]

So the point is, the content script is seeing String.prototype from that jsd context somehow.

And I only hit this if content methodjit is on.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #5)
> Henrik, does mozmill use jsd?  I'm seeing us creating all sorts of objects on a
> compartment with null principals from _newJSDContext, and that's the
> compartment |c| is when I hit the assert.

No, we don't use any jsd interface nor component at the moment. The code of the extension can be found here:

https://github.com/mozautomation/mozmill/tree/hotfix-1.5.1/mozmill/mozmill/extension/

Comment 8

[Boris Zbarsky [:bzbarsky]]

OK.  Well, if you put actual useful steps to reproduce in the bug I can try to reproduce what you're seeing; otherwise we'll debug the jsd thing and hope it fixes your problem.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Those steps are needed to run the Mozmill tests:

* Install Mozmill from pypi: "pip install mozmill"
* Get the Mozmill tests from http://hg.mozilla.org/qa/mozmill-tests/
* Execute Mozmill: "mozmill -b %app% -t firefox/testSearch/"

Comment 10

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Proposed fix v1

The problem here is that global is a sandbox whose proto is a wrapped window. GetNativeOfWrapper walks the prototype chain looking for the wrapped native so we find the window and think that we're dealing with a window. Instead, we should just return here.

Comment 11

[Robert Sayre]

What's the next step here?

Comment 12

[Blake Kaplan (:mrbkap) (inactive)]

http://hg.mozilla.org/tracemonkey/rev/017a0aaab245

Comment 13

[Blake Kaplan (:mrbkap) (inactive)]

Tried again http://hg.mozilla.org/tracemonkey/rev/cc202b48606f

Comment 14

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/017a0aaab245

Comment 15

[Blake Kaplan (:mrbkap) (inactive)]

The backout also landed on m-c. I'll re-land this tomorrow.

Comment 16

[Robert Sayre]

Any news?

Comment 17

[Blake Kaplan (:mrbkap) (inactive)]

http://hg.mozilla.org/mozilla-central/rev/cc202b48606f

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This bug has not been fixed by the latest check-in. Assertion and crash is still happening when running our Mozmill tests for the search bar.

Tested with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101212 Firefox/4.0b8pre

Comment 19

[Andreas Gal :gal]

Henrik, is the stack identical?

Comment 20

[Andreas Gal :gal]

We need to see the stack for comment 18. This bug fixed one compartments mismatch, so we should clone it and close this one. Also, this kind of bugs are most likely not fatal in a product build until we land per-compartment GC, so the clone can block b9 (we will try to figure it out today whats going on, just to be sure though). Also, you could really help us out if you can make a reproducible test case for us as part of any of the standard firefox test harnesses instead of the custom harness in mozmill.

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+2]]

The assertion doesn't occur anymore when I run our Mozmill tests with the latest debug tinderbox build. Marking as verified fixed with  Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20110107 Firefox/4.0b9pre

Comment 22

[Andreas Gal :gal]

Thanks Henrik.