The default bug view has changed. See this FAQ.

"Assertion failure: hasAllFlags(OBJECT_FLAG_DYNAMIC_MASK),"

VERIFIED FIXED in Firefox 15

Status

()

Core
JavaScript Engine
--
critical
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: gkw, Assigned: till)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
mozilla15
x86_64
Linux
assertion, regression, sec-critical, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox14 unaffected, firefox15 fixed, firefox-esr10 unaffected)

Details

(Whiteboard: js-triage-done)

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Created attachment 625472 [details]
stack

o0 = {};
g = new ArrayBuffer;
g2 = this;
v = g2.o0.t;
o0 = Object;
print(
    {
        x: gc(gcPreserveCode())
    }
);
for (z = 0; z < 3; z) {}

asserts js debug shell on m-c changeset 642d1a36702f with -m and -n at Assertion failure: hasAllFlags(OBJECT_FLAG_DYNAMIC_MASK),

Tested on 64-bit.

gcPreserveCode seems to be involved but I have no idea how serious this might be, setting s-s to be safe.

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   94390:5232403e7b8f
user:        Till Schneidereit
date:        Fri May 18 13:35:43 2012 -0400
summary:     Bug 755604 - Incrementalize JSCompartment::markTypes. r=billm
(Assignee)

Comment 1

5 years ago
Created attachment 625500 [details] [diff] [review]
fix

The attached patch fixes the assert.

The problem was a missing call to object->markIfUnmarked before GCMarker::pushObject.

I wonder if maybe pushObject and friends should assert that their targets have been marked to prevent similar issues in the future?
Assignee: general → tschneidereit+bmo
Status: NEW → ASSIGNED
Attachment #625500 - Flags: review?(wmccloskey)
(Assignee)

Comment 2

5 years ago
Pushed to try: https://tbpl.mozilla.org/?tree=Try&rev=786e061ae7f3
Comment on attachment 625500 [details] [diff] [review]
fix

Oops, sorry. I should have caught this.
Attachment #625500 - Flags: review?(wmccloskey) → review+
(Assignee)

Comment 4

5 years ago
Thanks Bill!
Keywords: checkin-needed
Whiteboard: js-triage-needed
Blocks: 756796
Pushed to m-c.

https://hg.mozilla.org/mozilla-central/rev/fb3036d9b9e6
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla15
Keywords: checkin-needed
Possible to write a test for this?
Flags: in-testsuite?
status-firefox14: --- → unaffected
status-firefox15: --- → fixed
(Assignee)

Comment 7

5 years ago
I guess I can massage the fuzzer result into a somewhat sane test. Will ask on #jsapi for details.
JSBugMon: This bug has been automatically verified fixed.
Status: RESOLVED → VERIFIED
(Reporter)

Updated

5 years ago
Whiteboard: js-triage-done

Comment 9

5 years ago
I guess this can be opened now as it only affected trunk and is verified and in today's Nightly, right?
Duplicate of this bug: 756779
Duplicate of this bug: 756778
Blocks: 756798
Blocks: 756797
The crash stacks in bug 756796 look sec-critical
status-firefox-esr10: --- → unaffected
Keywords: sec-critical
Group: core-security

Updated

5 years ago
Duplicate of this bug: 756863
Test added:

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