Closed
Bug 599672
Opened 15 years ago
Closed 15 years ago
Assertion failure "non-global object at end of scope chain" trying to dump cycle collector heap
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
| Tracking | Status | |
|---|---|---|
| blocking2.0 | --- | beta7+ |
People
(Reporter: roc, Assigned: mrbkap)
Details
(Whiteboard: fixed-in-tracemonkey)
Attachments
(1 file)
|
1.62 KB,
patch
|
cdleary
:
review+
|
Details | Diff | Splinter Review |
Steps to reproduce:
1) Start a debug build
2) Enable Error Console by setting devtools.errorconsole.enabled to true in about:config
3) Open a new window
4) Open the Error Console via the Tools menu
5) Evaluate the expression:
window.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components.interfaces.nsIDOMWindowUtils).garbageCollect(Components.classes["@mozilla.org/cycle-collector-logger;1"].createInstance(Components.interfaces.nsICycleCollectorListener))
(gdb) where
#0 0x00712f9d in JS_Assert (s=0x85fdfc "non-global object at end of scope chain", file=0x85fdd0 "/Users/roc/mozilla-checkin/js/src/jsobj.cpp", ln=6137) at /Users/roc/mozilla-checkin/js/src/jsutil.cpp:80
#1 0x0066ecd8 in JSObject::getCompartment (this=0x19712c60, cx=0x1ac68490) at /Users/roc/mozilla-checkin/js/src/jsobj.cpp:6137
#2 0x005bf996 in js::CompartmentChecker::check (this=0xbfff7a68, obj=0x19712c60) at jscntxtinlines.h:538
#3 0x005c26d5 in js::assertSameCompartment<JSObject*> (cx=0x1ac68490, t1=0x19712c60) at jscntxtinlines.h:598
#4 0x005a1a88 in JS_GetParent (cx=0x1ac68490, obj=0x19712c60) at /Users/roc/mozilla-checkin/js/src/jsapi.cpp:2879
#5 0x1340fff5 in nsXPConnect::Traverse (this=0xe526f0, p=0x19712c60, cb=@0xbfff7ce4) at /Users/roc/mozilla-checkin/js/src/xpconnect/src/nsXPConnect.cpp:796
#6 0x00beaf2a in GCGraphBuilder::Traverse (this=0xbfff7ce4, aPtrInfo=0x1ae4b23c) at /Users/roc/mozilla-checkin/xpcom/base/nsCycleCollector.cpp:1491
#7 0x00beafc8 in nsCycleCollector::MarkRoots (this=0x1006000, builder=@0xbfff7ce4) at /Users/roc/mozilla-checkin/xpcom/base/nsCycleCollector.cpp:1732
#8 0x00beb12c in nsCycleCollector::BeginCollection (this=0x1006000, aListener=0x1acc2e20) at /Users/roc/mozilla-checkin/xpcom/base/nsCycleCollector.cpp:2612
#9 0x00beb3a2 in nsCycleCollector::Collect (this=0x1006000, aTryCollections=1, aListener=0x1acc2e20) at /Users/roc/mozilla-checkin/xpcom/base/nsCycleCollector.cpp:2490
#10 0x00beb486 in nsCycleCollector_collect (aListener=0x1acc2e20) at /Users/roc/mozilla-checkin/xpcom/base/nsCycleCollector.cpp:3208
#11 0x12ec6562 in nsJSContext::CC (aListener=0x1acc2e20) at /Users/roc/mozilla-checkin/dom/base/nsJSEnvironment.cpp:3531
#12 0x12ebfe7d in nsDOMWindowUtils::GarbageCollect (this=0x1ab7ee30, aListener=0x1acc2e20) at /Users/roc/mozilla-checkin/dom/base/nsDOMWindowUtils.cpp:655
#13 0x00bf09ed in NS_InvokeByIndex_P (that=0x1ab7ee30, methodIndex=21, paramCount=1, params=0xbfffbe18) at /Users/roc/mozilla-checkin/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:179
| Reporter | ||
Comment 1•15 years ago
|
||
We need this to be fixed ASAP so we can get heap dumps to track down leaks.
blocking2.0: --- → ?
Comment 2•15 years ago
|
||
Might be an artifact of using the error console. If you put that code in an extension and trigger it from a menu item or something, does it still happen?
I can try with a debug build tomorrow, but with my desktop still trapped in Toronto it's not going to be very efficient.
| Reporter | ||
Comment 3•15 years ago
|
||
(In reply to comment #2)
> Might be an artifact of using the error console. If you put that code in an
> extension and trigger it from a menu item or something, does it still happen?
I don't know. However, this used to work via the Error Console, and it's highly desirable that we can tell people how to produce heap dumps without requiring an extension. (Although I suppose a restartless extension would be OK.)
Comment 4•15 years ago
|
||
Yes, it would be restartless. If you get it in the debugger again, can you get a fuller stack, and inspect the object that is found at the top of the scope chain? Betting there's just a JSCLASS_IS_GLOBAL_OBJECT flag missing somewhere.
| Reporter | ||
Comment 5•15 years ago
|
||
(gdb) up
#2 0x00007ffff6acf10b in JSObject::getCompartment (this=0x7fffd2c3f460, cx=
0x7fffd3a2c400) at /home/roc/mozilla-central/js/src/jsobj.cpp:6317
6317 JS_NOT_REACHED("non-global object at end of scope chain");
(gdb) p *obj
$3 = {{lastProp = 0x7fffcd8409e0, map = 0x7fffcd8409e0}, clasp = 0x7ffff7f71fa0, flags = 0, objShape = 121598, proto =
0x0, parent = 0x0, dslots = 0x0, emptyShape = 0x0, fslots = {{data = {
asBits = 140736641293952, debugView = {payload47 = 140736641293952,
tag = 0}, s = {payload = {i32 = -847061376, u32 = 3447905920, why =
3447905920}}, asDouble = 6.9533139574424243e-310, asPtr =
0x7fffcd82de80}}, {data = {asBits = 18444773748872577024, debugView = {
payload47 = 0, tag = JSVAL_TAG_UNDEFINED}, s = {payload = {i32 = 0,
u32 = 0, why = JS_ARRAY_HOLE}}, asDouble = -nan(0x9000000000000),
asPtr = 0xfff9000000000000}}, {data = {asBits = 18444773748872577024,
debugView = {payload47 = 0, tag = JSVAL_TAG_UNDEFINED}, s = {payload =
{i32 = 0, u32 = 0, why = JS_ARRAY_HOLE}}, asDouble =
-nan(0x9000000000000), asPtr = 0xfff9000000000000}}}, title = {ownercx =
0x7fffd3a2c400, lock = {owner = 0, fat = 0x0}, u = {count = 0, link =
0x0}},
| Reporter | ||
Comment 6•15 years ago
|
||
(gdb) p *(obj->clasp)
$4 = {name = 0x7ffff734f93c "RegExpStatics", flags = 524289, addProperty =
0x7ffff6a1e4dd <JS_PropertyStub(JSContext*, JSObject*, jsid, jsval*)>,
delProperty =
0x7ffff6a1e4dd <JS_PropertyStub(JSContext*, JSObject*, jsid, jsval*)>,
getProperty =
0x7ffff6a1e4dd <JS_PropertyStub(JSContext*, JSObject*, jsid, jsval*)>,
setProperty =
0x7ffff6a1e4dd <JS_PropertyStub(JSContext*, JSObject*, jsid, jsval*)>,
enumerate = 0x7ffff6a1e4f8 <JS_EnumerateStub(JSContext*, JSObject*)>,
resolve = 0x7ffff6a1e50b <JS_ResolveStub(JSContext*, JSObject*, jsid)>,
convert =
0x7ffff6a1e522 <JS_ConvertStub(JSContext*, JSObject*, JSType, jsval*)>,
finalize = 0x7ffff6b2738d <resc_finalize(JSContext*, JSObject*)>,
reserved0 = 0, checkAccess = 0, call = 0, construct = 0, xdrObject = 0,
hasInstance = 0, mark = 0x7ffff6b273c2 <resc_trace(JSTracer*, JSObject*)>,
ext = {equality = 0, outerObject = 0, innerObject = 0, iteratorObject = 0,
wrappedObject = 0}, ops = {lookupProperty = 0, defineProperty = 0,
getProperty = 0, setProperty = 0, getAttributes = 0, setAttributes = 0,
deleteProperty = 0, enumerate = 0, typeOf = 0, trace = 0, fix = 0,
thisObject = 0, clear = 0}, pad = '\000' <repeats 15 times>,
static NON_NATIVE = <optimized out>}
| Reporter | ||
Comment 7•15 years ago
|
||
(gdb) p obj
$6 = (JSObject *) 0x7fffd2c3f460
(gdb) p this
$7 = (JSObject * const) 0x7fffd2c3f460
| Assignee | ||
Comment 9•15 years ago
|
||
Attachment #478897 -
Flags: review?(cdleary)
Comment 10•15 years ago
|
||
Comment on attachment 478897 [details] [diff] [review]
Proposed fix
So basically all objects need parent chains that end in globals for compartment stuff to work nowadays. I should have realized it would be easy to specify a sensible parent when I originally wrote that code.
Attachment #478897 -
Flags: review?(cdleary) → review+
Updated•15 years ago
|
blocking2.0: ? → beta8+
| Reporter | ||
Comment 11•15 years ago
|
||
Can someone please land this so heap dumps work and we can start fixing leaks?
| Assignee | ||
Comment 12•15 years ago
|
||
With the recent compartments landing, this assertion actually went away. I'll land this patch tomorrow for good bookkeeping anyway, though.
| Assignee | ||
Comment 13•15 years ago
|
||
Whiteboard: fixed-in-tracemonkey
Updated•15 years ago
|
blocking2.0: beta8+ → beta7+
Comment 14•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•