Closed Bug 794494 Opened 7 years ago Closed 7 years ago

Crash [@ js::shadow::Object::numFixedSlots] or "Assertion failure: (l.asBits & 0x8000000000000000LL) == 0," or "Assertion failure: slot < numFixedSlots(),"

Categories

(Core :: JavaScript Engine, defect, critical)

x86_64
macOS
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla18
Tracking Status
firefox15 --- unaffected
firefox16 --- unaffected
firefox17 --- unaffected
firefox18 - fixed
firefox-esr10 --- unaffected
firefox-esr17 --- unaffected

People

(Reporter: gkw, Assigned: sfink)

References

(Blocks 1 open bug)

Details

(5 keywords, Whiteboard: [fuzzblocker][jsbugmon:update][adv-main18-])

Crash Data

Attachments

(3 files)

Attached file stack
gc();
(function() {
  Object.defineProperty(this, "x", {
	get: function() {
	  return y.subarray();
	}
  });
  y = new Uint8ClampedArray;
  w = new Set;
  w.add(x);
  gcslice(48);
}());
x
gc()
with({
  z: gcslice(2580)
}) {
  x
}
gc()

crashes js debug shell on m-c changeset df69d95f636c without any CLI arguments at js::shadow::Object::numFixedSlots

s-s because this involves gc and Uint8ClampedArray.
This is flooding the fuzzers so badly, setting [fuzzblocker].
Whiteboard: [jsbugmon:update] → [fuzzblocker][jsbugmon:update]
I've only been able to whittle this down slightly to

gc();
y = new Int8Array;
Object.defineProperty(this, "x", {
    get: function() {
	return y.subarray();
    }
});
w = new Set;
w.add(x);
gcslice(48);
y.subarray();
gc();
gcslice(2580);
y.subarray();
gc();
I should note that this is definitely mine, from bug 789295.
Assignee: general → sphink
Status: NEW → ASSIGNED
> I should note that this is definitely mine, from bug 789295.

(providing confirmation)

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   108046:9382a5a45acb
user:        Steve Fink
date:        Tue Sep 18 09:58:36 2012 -0700
summary:     Bug 789295 - Add special multi-view array buffer sweep pass to eliminate finalizers and thus allow background sweeping. r=billm
Blocks: 789295
Summary: Crash [@ js::shadow::Object::numFixedSlots] → Crash [@ js::shadow::Object::numFixedSlots] or "Assertion failure: (l.asBits & 0x8000000000000000LL) == 0,"
This sounds scary and easy to find, marking sec-critical.
Keywords: sec-critical
Attached file stack
function g() {
    switch (1) {
        default: primarySandbox = newGlobal();
    }
    return function(code) {
        try {
            evalcx(code, primarySandbox)
        } catch (e) {}
    }
}
function h(code) {
    f(code);
}
f = g(1);
h("var r=/(?!{)/;s=\"\";s.split(r);t2=new Uint8ClampedArray")
gc()
h("Object.defineProperty(this,\"v1\",{e:true,get:function(){t1}});");
h("\
    t=Uint8Array(t2.buffer);\
    Object.defineProperty(this,\"t1\",{\
        get:function(){return t.subarray()}\
    })\
")
verifyprebarriers()
h("v1")
gc()
gc()
h("Object(t1)")
gc()


Here's another testcase that asserts at Assertion failure: slot < numFixedSlots(),
Keywords: assertion
Summary: Crash [@ js::shadow::Object::numFixedSlots] or "Assertion failure: (l.asBits & 0x8000000000000000LL) == 0," → Crash [@ js::shadow::Object::numFixedSlots] or "Assertion failure: (l.asBits & 0x8000000000000000LL) == 0," or "Assertion failure: slot < numFixedSlots(),"
This might be causing some orange:
https://tbpl.mozilla.org/php/getParsedLog.php?id=15554002&tree=Mozilla-Inbound#error2
The line number in the topmost frame is for numFixedSlots.
When I sweep through ArrayBuffers to filter out their dead views (reversing the list in the process), I was clearing the multiview buffer link field on the old first view instead of the new first view. This caused the tracing code to erroneously think that the buffer had already been added to the multiview buffer list, and so the buffer didn't get swept. This could result in dead views lingering in its view list.
Attachment #665132 - Flags: review?(wmccloskey)
Attachment #665132 - Flags: review?(wmccloskey) → review+
https://hg.mozilla.org/mozilla-central/rev/0f0a5a9919ae
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
I don't think this needs to be tracking-firefox18. It was introduced with bug 789295, so it was only in the tree for a day or two. But it depends on how you manage these things.
Tracking- means it isn't being tracked. :)
Status: RESOLVED → VERIFIED
JSBugMon: This bug has been automatically verified fixed.
Whiteboard: [fuzzblocker][jsbugmon:update] → [fuzzblocker][jsbugmon:update][adv-main18-]
Group: core-security
You need to log in before you can comment on or make changes to this bug.