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

RESOLVED FIXED

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: decoder, Assigned: bhackett)

Tracking

(Blocks: 2 bugs, {assertion, testcase})

Other Branch
x86_64
Linux
assertion, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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);
(Reporter)

Updated

6 years ago
Version: Trunk → Other Branch
(Reporter)

Updated

6 years ago
Summary: TI: Assertion failure: type->canProvideEmptyShape(clasp), at ../jsobjinlines.h:1538 → [ObjShrink]: Assertion failure: type->canProvideEmptyShape(clasp), at ../jsobjinlines.h:1538
(Assignee)

Comment 1

6 years ago
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
Assignee: general → bhackett1024
Attachment #573299 - Flags: review?(luke)
(Assignee)

Comment 2

6 years ago
https://hg.mozilla.org/projects/jaegermonkey/rev/daf591298f5d
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 3

6 years ago
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?
Attachment #573299 - Flags: review?(luke) → review+
(Reporter)

Comment 4

4 years ago
Automatically extracted testcase for this bug was committed:

https://hg.mozilla.org/mozilla-central/rev/2e891e0db397
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.