Closed
Bug 951213
Opened 11 years ago
Closed 11 years ago
Assertion failure: canRemoveLastProperty(), at jsobjinlines.h:123
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla29
People
(Reporter: decoder, Assigned: bhackett1024)
References
Details
(Keywords: assertion, testcase, Whiteboard: [jsbugmon:update])
Attachments
(3 files, 1 obsolete file)
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
jandem
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
terrence
:
review+
|
Details | Diff | Splinter Review |
The following testcase asserts on mozilla-central revision b980c2dee2e7 (run with --fuzzing-safe --ion-eager):
setObjectMetadataCallback(function(obj) {});
function foo(x, y) {
this.g = x + y;
}
var a = 0;
var b = { valueOf: function() Object.defineProperty(Object.prototype, 'g', {}) };
var c = new foo(a, b);
Reporter | ||
Comment 1•11 years ago
|
||
Reporter | ||
Updated•11 years ago
|
Whiteboard: [jsbugmon:update,bisect]
Reporter | ||
Updated•11 years ago
|
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
Reporter | ||
Comment 2•11 years ago
|
||
JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:
The first bad revision is:
changeset: http://hg.mozilla.org/mozilla-central/rev/bec71542c055
user: Brian Hackett
date: Sat Dec 14 16:29:43 2013 -0800
summary: Bug 950118 - Don't allow the object metadata hook to reenter JS, r=jimb.
This iteration took 1.020 seconds to run.
Reporter | ||
Updated•11 years ago
|
Flags: needinfo?(bhackett1024)
Assignee | ||
Comment 3•11 years ago
|
||
The logic used when rolling back object properties when TI's definite properties analysis gets invalidated wasn't able to cope with objects that have metadata. JSObjet::removeProperty is a more generic API that can cope with this case.
Assignee: nobody → bhackett1024
Attachment #8350374 -
Flags: review?(jdemooij)
Flags: needinfo?(bhackett1024)
Assignee | ||
Comment 4•11 years ago
|
||
Oops, wrong patch.
Attachment #8350374 -
Attachment is obsolete: true
Attachment #8350374 -
Flags: review?(jdemooij)
Attachment #8350376 -
Flags: review?(jdemooij)
Updated•11 years ago
|
Attachment #8350376 -
Flags: review?(jdemooij) → review+
Assignee | ||
Comment 5•11 years ago
|
||
Backed out in http://hg.mozilla.org/integration/mozilla-inbound/rev/dcad449c5d00 for causing ggc test failures: https://tbpl.mozilla.org/php/getParsedLog.php?id=32296712&tree=Mozilla-Inbound
Assignee | ||
Comment 7•11 years ago
|
||
GGC builds break on the new testcase even without the patch. This patch fixes GGC to handle the testcase and avoids expensive enabling/disabling of the nursery every time the metadata callback is invoked.
Note that not rekeying initial shape table entries for nursery metadata things won't lead to any incorrect behavior, though some extra shapes might end up being created. The same holds for parent, but not proto --- |InitialShapeEntry::proto| should be fixed up, or subtly incorrect behavior (not crashes) could happen. (If the same |proto| address is used for two different prototype objects then objects with different protos could have the same shape, which will confuse jitcode prototype-traversing caches.) It would be best if this behaved like TypeObjectWithNewScriptEntry, though again this is a separate issue from this patch.
Attachment #8351494 -
Flags: review?(terrence)
Comment 8•11 years ago
|
||
Comment on attachment 8351494 [details] [diff] [review]
updated
Review of attachment 8351494 [details] [diff] [review]:
-----------------------------------------------------------------
Great! r=me
The InitialShapeSet issue is worrisome. I'll file a bug.
Attachment #8351494 -
Flags: review?(terrence) → review+
Assignee | ||
Comment 10•11 years ago
|
||
Comment 11•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
Updated•11 years ago
|
Flags: in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•