Last Comment Bug 682298 - "Assertion failure: compartment mismatched," or "Assertion failure: addr % Cell::CellSize == 0," or "Assertion failure: Chunk::withinArenasRange(addr),"
: "Assertion failure: compartment mismatched," or "Assertion failure: addr % Ce...
Status: RESOLVED FIXED
[inbound]
: assertion, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86 Windows 7
: -- critical (vote)
: mozilla9
Assigned To: Jason Orendorff [:jorendorff]
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-26 08:25 PDT by Gary Kwong [:gkw] [:nth10sd]
Modified: 2013-01-19 13:59 PST (History)
7 users (show)
choller: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
v1 (899 bytes, patch)
2011-08-26 11:18 PDT, Jason Orendorff [:jorendorff]
luke: review+
Details | Diff | Splinter Review

Description Gary Kwong [:gkw] [:nth10sd] 2011-08-26 08:25:54 PDT
(function(){clear()})()

asserts js debug shell on mozilla-central changeset cc1e08803869 without any CLI arguments at Assertion failure: compartment mismatched, or Assertion failure: addr % Cell::CellSize == 0, or Assertion failure: Chunk::withinArenasRange(addr),

Thanks jorendorff for assistance on IRC.

This was found using a triple combination of an existing js test, jsfunfuzz and jandem's method fuzzer. Eventually the reduced testcase revealed jsfunfuzz and jandem's fuzzer output was not needed for the assert.
Comment 1 Christian Holler (:decoder) 2011-08-26 08:43:12 PDT
clear() is on my list of unsafe shell-only functions (like parent and trap) that can cause false positives and should only be used internally.

It would be interesting to know if the issue revealed here is caused by clear() itself of if the underlying issue is a defect and clear() just exposed it easier.
Comment 2 Jan de Mooij [:jandem] 2011-08-26 08:52:54 PDT
(In reply to Christian Holler (:decoder) from comment #1)
> It would be interesting to know if the issue revealed here is caused by
> clear() itself of if the underlying issue is a defect and clear() just
> exposed it easier.

It's caused by clear() itself:
===
static JSBool
Clear(JSContext *cx, uintN argc, jsval *vp)
{
    JSObject *obj;
    if (argc != 0 && !JS_ValueToObject(cx, JS_ARGV(cx, vp)[0], &obj))
        return JS_FALSE;
    JS_ClearScope(cx, obj);
    JS_SET_RVAL(cx, vp, JSVAL_VOID);
    return JS_TRUE;
}
===
obj is garbage if argc == 0
Comment 3 Gary Kwong [:gkw] [:nth10sd] 2011-08-26 09:31:02 PDT
function f() {
  clear(this)
}
f()
v = function() {}

This also causes Assertion failure: fun->getProto() == proto, with -n on JM changeset d60ffe67a13f
Comment 4 Brian Hackett (:bhackett) 2011-08-26 11:18:19 PDT
(In reply to Gary Kwong [:gkw, :nth10sd] from comment #3)
> function f() {
>   clear(this)
> }
> f()
> v = function() {}
> 
> This also causes Assertion failure: fun->getProto() == proto, with -n on JM
> changeset d60ffe67a13f

This testcase is misusing clear(), after the scope is cleared on a global object no more scripts should run against that global (an engine wide invariant which the JITs and TI depend on heavily).
Comment 5 Jason Orendorff [:jorendorff] 2011-08-26 11:18:40 PDT
Created attachment 556079 [details] [diff] [review]
v1

Sigh.
Comment 6 Gary Kwong [:gkw] [:nth10sd] 2011-08-29 20:40:25 PDT
(In reply to Jason Orendorff [:jorendorff] from comment #5)
> Created attachment 556079 [details] [diff] [review]
> v1

Should this be checked in soon since there's r+?

(In reply to Brian Hackett from comment #4)
> This testcase is misusing clear(), after the scope is cleared on a global
> object no more scripts should run against that global (an engine wide
> invariant which the JITs and TI depend on heavily).

Brian, is this also fixed in TI (if there's a TI issue present)?
Comment 7 Brian Hackett (:bhackett) 2011-08-29 21:41:54 PDT
(In reply to Gary Kwong [:gkw, :nth10sd] from comment #6)
> (In reply to Brian Hackett from comment #4)
> > This testcase is misusing clear(), after the scope is cleared on a global
> > object no more scripts should run against that global (an engine wide
> > invariant which the JITs and TI depend on heavily).
> 
> Brian, is this also fixed in TI (if there's a TI issue present)?

There is no TI issue present, clear() cannot be used in this way in the browser.
Comment 8 Jason Orendorff [:jorendorff] 2011-08-30 17:40:44 PDT
(In reply to Gary Kwong [:gkw, :nth10sd] from comment #6)
> Should this be checked in soon since there's r+?

Heh! It got r+ on Friday. Today is Tuesday. I was busy Monday!  :)

http://hg.mozilla.org/integration/mozilla-inbound/rev/efcd1318cf4d
Comment 9 Marco Bonardo [::mak] 2011-08-31 02:08:15 PDT
http://hg.mozilla.org/mozilla-central/rev/efcd1318cf4d
Comment 10 Christian Holler (:decoder) 2013-01-19 13:59:39 PST
Automatically extracted testcase for this bug was committed:

https://hg.mozilla.org/mozilla-central/rev/efaf8960a929

Note You need to log in before you can comment on or make changes to this bug.