Closed
Bug 832103
Opened 12 years ago
Closed 12 years ago
Crash [@ PropertyAccess<(PropertyAccessKind)1>] or [@ js::types::TypeCompartment::resolvePending] or "Assertion failure: hasAllFlags(OBJECT_FLAG_DYNAMIC_MASK),"
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
VERIFIED
FIXED
mozilla21
Tracking | Status | |
---|---|---|
firefox18 | --- | unaffected |
firefox19 | --- | unaffected |
firefox20 | --- | unaffected |
firefox21 | + | fixed |
firefox-esr10 | --- | unaffected |
firefox-esr17 | --- | unaffected |
b2g18 | --- | unaffected |
People
(Reporter: gkw, Unassigned)
References
Details
(5 keywords, Whiteboard: [jsbugmon:])
Crash Data
Attachments
(2 files)
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
bhackett1024
:
review+
|
Details | Diff | Splinter Review |
RegExp("").exec()
Object.defineProperty(this, "x", {
get: function() {
return new Array
}
})
Object.defineProperty(this, "y", {
get: function() {
return [function() {}, 0, 0, 0, 0, 0, 0]
}
})
r = RegExp("");
uneval(undefined)
with({
b: gczeal(9, 2)
});
r = /()/;
y.sort(function(j) {
if (j) {
a =
new
Array
} else {
x.v()
}
})
asserts js debug shell on m-c changeset ce9cdd801a73 with -a at Assertion failure: hasAllFlags(OBJECT_FLAG_DYNAMIC_MASK), and crashes js opt shell at PropertyAccess<(PropertyAccessKind)1> with js::types::TypeCompartment::resolvePending on the stack.
s-s and assuming sec-critical because weird memory address 0x7ffff653200000 is being accessed.
autoBisect shows this is probably related to the following changeset:
The first bad revision is:
changeset: 118821:6acc72608961
user: Terrence Cole
date: Fri Nov 09 09:45:25 2012 -0800
summary: Bug 811060 - Move DeflateString out of jsstr and make it Typey; r=Waldo
Changeset 6acc72608961 only landed on m-c on January 15, so this should only affect nightlies (Firefox 21).
Reporter | ||
Comment 1•12 years ago
|
||
Terrence, do you think bug 811060 is a possible regressor?
Flags: needinfo?(terrence)
Reporter | ||
Comment 2•12 years ago
|
||
On hindsight, I think the testcase can be reduced a little bit more, but I'll leave it to others here...
Updated•12 years ago
|
Updated•12 years ago
|
Crash Signature: [@ PropertyAccess<(PropertyAccessKind)1>]
[@ js::types::TypeCompartment::resolvePending] → [@ PropertyAccess<(PropertyAccessKind)1>]
[@ js::types::TypeCompartment::resolvePending]
Whiteboard: [jsbugmon:update] → [jsbugmon:update,ignore]
Comment 3•12 years ago
|
||
JSBugMon: The testcase found in this bug no longer reproduces (tried revision 02e12a80aef9).
Updated•12 years ago
|
Crash Signature: [@ PropertyAccess<(PropertyAccessKind)1>]
[@ js::types::TypeCompartment::resolvePending] → [@ PropertyAccess<(PropertyAccessKind)1>]
[@ js::types::TypeCompartment::resolvePending]
Whiteboard: [jsbugmon:update,ignore] → [jsbugmon:bisectfix]
Updated•12 years ago
|
Crash Signature: [@ PropertyAccess<(PropertyAccessKind)1>]
[@ js::types::TypeCompartment::resolvePending] → [@ PropertyAccess<(PropertyAccessKind)1>]
[@ js::types::TypeCompartment::resolvePending]
Whiteboard: [jsbugmon:bisectfix] → [jsbugmon:]
Comment 4•12 years ago
|
||
JSBugMon: Fix Bisection requested, result:
autoBisect shows this is probably related to the following changeset:
The first good revision is:
changeset: 119272:7b531a62b114
user: Brian Hackett
date: Fri Jan 18 09:23:28 2013 -0700
summary: Bug 772820 - Disallow GCs during script analysis or compilation, r=billm.
This iteration took 97.646 seconds to run.
Comment 5•12 years ago
|
||
Brian, did the rev in comment 4 fix this issue?
Crash Signature: [@ PropertyAccess<(PropertyAccessKind)1>]
[@ js::types::TypeCompartment::resolvePending] → [@ PropertyAccess<(PropertyAccessKind)1>]
[@ js::types::TypeCompartment::resolvePending]
Flags: needinfo?(bhackett1024)
Comment 6•12 years ago
|
||
No idea. These GC tests are super fragile and bug 772820 can affect when they occur.
Flags: needinfo?(bhackett1024)
Comment 7•12 years ago
|
||
I have to second Brian here: I can't see how either of these patches would have impacted this other than random GC timing changes. We might as well just add the test to the suite so that if it shows up again we'll know and can take a look at it then.
Attachment #709770 -
Flags: review?(bhackett1024)
Flags: needinfo?(terrence)
Comment 8•12 years ago
|
||
I managed to reproduce this on the given revision and it appears to just be very random -- not surprising since the problems is we're accessing a dead (background finalized) thing. It appears to always flow out of the stack (|lval|, |regs.sp[-1]|, etc) and it appears to be flowing out of JM -- JM does the last assignment to the stack slot before the next, crashing access. I was still not able to reproduce on tip, however.
Brian, do you know of any recent rooting changes at the boundary of JM that would have fixed this?
QA Contact: general
Comment 9•12 years ago
|
||
Comment on attachment 709770 [details] [diff] [review]
v0: add test to jit-tests
New tests don't need review.
Attachment #709770 -
Flags: review?(bhackett1024) → review+
Comment 10•12 years ago
|
||
Sorry for the bother, I totally forgot about that rule!
https://hg.mozilla.org/integration/mozilla-inbound/rev/36e03cf9cb41
Comment 11•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/36e03cf9cb41
(Not sure if this needs resolving at this point or not...)
Flags: in-testsuite+
Reporter | ||
Comment 12•12 years ago
|
||
Let's assume the vague possibility that bug 772820 fixed it.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 13•12 years ago
|
||
VERIFIED because in-testsuite+ - the test landed.
Status: RESOLVED → VERIFIED
Updated•12 years ago
|
Target Milestone: --- → mozilla21
Updated•12 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•