The default bug view has changed. See this FAQ.

"Assertion failure: compartment mismatched," or "Assertion failure: addr % Cell::CellSize == 0," or "Assertion failure: Chunk::withinArenasRange(addr),"

RESOLVED FIXED in mozilla9

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: gkw, Assigned: jorendorff)

Tracking

({assertion, testcase})

Trunk
mozilla9
x86
Windows 7
assertion, testcase
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [inbound])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
(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.
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.
(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
(Reporter)

Comment 3

6 years ago
function f() {
  clear(this)
}
f()
v = function() {}

This also causes Assertion failure: fun->getProto() == proto, with -n on JM changeset d60ffe67a13f
(Assignee)

Updated

6 years ago
Assignee: general → jorendorff
Group: core-security
(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).
(Assignee)

Comment 5

6 years ago
Created attachment 556079 [details] [diff] [review]
v1

Sigh.
Attachment #556079 - Flags: review?(luke)

Updated

6 years ago
Attachment #556079 - Flags: review?(luke) → review+
(Reporter)

Comment 6

6 years ago
(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)?
(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.
(Assignee)

Comment 8

6 years ago
(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
Whiteboard: js-triage-needed → [inbound]
http://hg.mozilla.org/mozilla-central/rev/efcd1318cf4d
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla9
Automatically extracted testcase for this bug was committed:

https://hg.mozilla.org/mozilla-central/rev/efaf8960a929
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.