Last Comment Bug 698150 - [ObjShrink]: Assertion failure: type->canProvideEmptyShape(clasp), at ../jsobjinlines.h:1538
: [ObjShrink]: Assertion failure: type->canProvideEmptyShape(clasp), at ../jsob...
Status: RESOLVED FIXED
: assertion, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Other Branch
: x86_64 Linux
: -- critical (vote)
: ---
Assigned To: Brian Hackett (:bhackett)
:
: Jason Orendorff [:jorendorff]
Mentors:
Depends on:
Blocks: infer-regress langfuzz
  Show dependency treegraph
 
Reported: 2011-10-28 16:42 PDT by Christian Holler (:decoder)
Modified: 2013-02-07 05:17 PST (History)
4 users (show)
choller: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (7.88 KB, patch)
2011-11-09 13:19 PST, Brian Hackett (:bhackett)
luke: review+
Details | Diff | Splinter Review

Description Christian Holler (:decoder) 2011-10-28 16:42:08 PDT
The following testcase asserts on jaegermonkey revision b01eb1ba58ce (run with -m -n), tested on 64 bit:


gczeal(2);
var g1 = newGlobal('same-compartment');
var proxyStr = "Proxy.create(                                    "+
"  { getOwnPropertyDescriptor: function() assertEq(true,false),  "+
"    fix: function() assertEq(true,false), },                    "+
"  Object.prototype                                              "+
");                                                              ";
var proxy1 = g1.eval(proxyStr);
Comment 1 Brian Hackett (:bhackett) 2011-11-09 13:19:07 PST
Created attachment 573299 [details] [diff] [review]
patch

More fallout from changing strong references on new types to weak references.  When initializing certain standard classes, the VM makes sure to instantiate an empty shape for that class with an appropriate class.  Otherwise the class of the empty shapes associated with a type is that specified the first time an object is created with the proto.  This is a kind of goofy and long standing behavior and the VM's attempt to ensure the shapes are instantiated with the right class doesn't work when the shapes are only weakly held.

The patch changes things so that the empty shapes on the type must have the same class as the prototype.  This is vulnerable to creating pathological behavior when lots of objects get created with a mismatched class (they will all have separate shape lineages), but this design has always been subject to such problems.  I will measure and if lots of new empty shapes are being constructed because of mismatches here then the whole bit needs to be reworked.

https://hg.mozilla.org/projects/jaegermonkey/rev/daf591298f5d
Comment 2 Brian Hackett (:bhackett) 2011-11-09 13:19:25 PST
https://hg.mozilla.org/projects/jaegermonkey/rev/daf591298f5d
Comment 3 Luke Wagner [:luke] 2011-11-16 12:08:04 PST
Comment on attachment 573299 [details] [diff] [review]
patch

On the subject, EmptyShape::create implies a new empty shape is created (as is the case for all these *Object::create functions); could you name it EmptyShape::get instead?
Comment 4 Christian Holler (:decoder) 2013-02-07 05:17:52 PST
Automatically extracted testcase for this bug was committed:

https://hg.mozilla.org/mozilla-central/rev/2e891e0db397

Note You need to log in before you can comment on or make changes to this bug.