Printing JS stacks hits fatal asserts

RESOLVED FIXED in mozilla12

Status

()

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

People

(Reporter: bz, Assigned: bhackett)

Tracking

({regression})

Trunk
mozilla12
x86
Mac OS X
regression
Points:
---

Firefox Tracking Flags

(firefox11+ wontfix)

Details

Attachments

(2 attachments)

Stack looks like this:

#0  0x011b7698 in CrashInJS () at ../../../mozilla/js/src/jsutil.cpp:92
#1  0x011b7701 in JS_Assert (s=0x1380d58 "hasSlot() && !hasMissingSlot()", file=0x1380c5c "../../../mozilla/js/src/jsscope.h", ln=762) at ../../../mozilla/js/src/jsutil.cpp:103
#2  0x010d0642 in js::Shape::slot (this=0x224ad430) at jsscope.h:762
#3  0x01077fd5 in JS_GetPropertyDesc (cx=0x1db010, obj=0x224b0940, sprop=0x224ad430, pd=0x64cd590) at ../../../mozilla/js/src/jsdbgapi.cpp:864

Line 864 of jsdbgapi.cpp is:

    if (obj->containsSlot(shape->slot())) {

and in this case |shape->hasSlot()| is false.

It looks like there shoud be an explicit hasSlot check here, perhaps?  Is the containsSlot() check still needed, then?

This is preventing use of DumpJSStack, which is a serious problem for browser debugging....
(Note that there seem to be other uses of containsSlot(shape->slot()) that aren't guarded by hasSlot(); I'm not sure why they're safe.)
tracking-firefox11: --- → ?
Version: 9 Branch → Trunk
(Assignee)

Comment 2

6 years ago
Created attachment 581635 [details] [diff] [review]
rm JSObject::containsSlot

Remove obj->containsSlot() entirely.  There isn't any situation where it is correct to use containsSlot instead of shape->hasSlot().  This also fixes some broken logic in js_PrintObjectSlotName.
Assignee: general → bhackett1024
Attachment #581635 - Flags: review?(luke)

Updated

6 years ago
Attachment #581635 - Flags: review?(luke) → review+
Comment on attachment 581635 [details] [diff] [review]
rm JSObject::containsSlot

Is the jsdbgapi code not needed anymore?
(Assignee)

Comment 4

6 years ago
The jsdbgapi code is looking for a second shape which has the same slot as the first shape.  It used to be possible that two properties on an object could alias each other in this way, but this is no longer the case.

https://hg.mozilla.org/integration/mozilla-inbound/rev/36fa9b176a91
(Assignee)

Comment 5

6 years ago
Backed out due to M1 orange:

https://hg.mozilla.org/integration/mozilla-inbound/rev/c5ebfdbe12d9
Created attachment 583244 [details] [diff] [review]
Rebased patch

I rebased the patch to be able to print js stacks while debugging something else.
(Assignee)

Comment 7

6 years ago
Relanding.  Some method barrier code gets invoked during property deletion, and this was happening after calling a hook which could remove the shape from the object.

https://hg.mozilla.org/integration/mozilla-inbound/rev/2c7cd0b499ba

Comment 8

6 years ago
https://hg.mozilla.org/mozilla-central/rev/2c7cd0b499ba
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla12

Comment 9

6 years ago
](In reply to Brian Hackett (:bhackett) from comment #4)
> The jsdbgapi code is looking for a second shape which has the same slot as
> the first shape.  It used to be possible that two properties on an object
> could alias each other in this way, but this is no longer the case.
> 
> https://hg.mozilla.org/integration/mozilla-inbound/rev/36fa9b176a91

If this will significantly affect dev debugging for 11, please nominate for approval on Aurora 11 as soon as possible.
tracking-firefox11: ? → +

Updated

5 years ago
status-firefox11: --- → wontfix
You need to log in before you can comment on or make changes to this bug.