Closed Bug 951346 Opened 7 years ago Closed 7 years ago

Assertion failure: obj->lastProperty() == p->value().shape, at jsinfer.cpp:2545


(Core :: JavaScript Engine, defect)

Not set





(Reporter: decoder, Assigned: bhackett1024)


(Keywords: assertion, testcase, Whiteboard: [jsbugmon:update])


(2 files, 1 obsolete file)

The following testcase asserts on mozilla-central revision b980c2dee2e7 (run with --fuzzing-safe):

setObjectMetadataCallback(function(obj) {});
Whiteboard: [jsbugmon:update,bisect]
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
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.373 seconds to run.
Flags: needinfo?(bhackett1024)
Attached patch patchSplinter Review
It should be fine to just skip fixObjectType (a TI optimization to improve type information) for objects with metadata.
Assignee: nobody → bhackett1024
Attachment #8350369 - Flags: review?(jimb)
Flags: needinfo?(bhackett1024)
We'd like to attach metadata to pretty much all objects, when the heap analysis tools are on. Is it hard to preserve the optimization?
Flags: needinfo?(bhackett1024)
Attachment #8348967 - Attachment is obsolete: true
(In reply to Jim Blandy :jimb from comment #4)
> We'd like to attach metadata to pretty much all objects, when the heap
> analysis tools are on. Is it hard to preserve the optimization?

The metadata could be added to the lookup/key part of the table, which would work but would be pretty complicated to get right with generational GC --- if metadata objects are in the nursery (which would be nice to permit, but could be restricted I guess with some new JSAPI for the callback to use) then table entries referring to nursery objects would need to be rekeyed on minor GCs.  We do stuff like this for the new object type table (NewTypeObjectsSetRef), but it's pretty complicated and not well encapsulated and would be good to avoid for tables when possible.

Disabling the optimization won't affect performance that much and won't affect the object graph at all, and since we already inhibit optimizations when the metadata callback is on this simple option doesn't seem too out of character.
Flags: needinfo?(bhackett1024)
Comment on attachment 8350369 [details] [diff] [review]

Review of attachment 8350369 [details] [diff] [review]:

Looks good to me --- but please add a brief comment explaining that we want to avoid including metadata objects in the key. (These chains of excluded cases get pretty obscure pretty fast...)
Attachment #8350369 - Flags: review?(jimb) → review+
Brian, can we land this? Thanks!
Flags: needinfo?(bhackett1024)
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
QA Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.