698150 - [ObjShrink]: Assertion failure: type->canProvideEmptyShape(clasp), at ../jsobjinlines.h:1538

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

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 [Laid off!]]

Attachment: 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 [Laid off!]]

https://hg.mozilla.org/projects/jaegermonkey/rev/daf591298f5d

Comment 3

[Luke Wagner [:luke]]

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)]

Automatically extracted testcase for this bug was committed:

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