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

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.

Comment on attachment 581635 [details] [diff] [review] rm JSObject::containsSlot Is the jsdbgapi code not needed anymore?

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

Backed out due to M1 orange: https://hg.mozilla.org/integration/mozilla-inbound/rev/c5ebfdbe12d9

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

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

](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.