Stack: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 js::DebugScopes::hasDebugScope(JSContext*, js::ScopeObject&) const + 79 (Utility.h:890) 1 GetDebugScopeForScope(JSContext*, JS::Handle<js::ScopeObject*>, js::ScopeIter const&) + 49 (ScopeObject.cpp:1847) 2 GetDebugScope(JSContext*, js::ScopeIter const&) + 915 (Utility.h:716) 3 js::GetDebugScopeForFrame(JSContext*, js::StackFrame*) + 171 (Utility.h:716) 4 JS_GetFrameCallObject + 116 (jsdbgapi.cpp:573) 5 xpc_PrintJSStack(JSContext*, int, int, int) + 3584 (XPCDebug.cpp:92) 6 xpc_DebuggerKeywordHandler(JSContext*, JSScript*, unsigned char*, JS::Value*, void*) + 71 (XPCDebug.cpp:267) 7 js::Interpret(JSContext*, js::StackFrame*, js::InterpMode) + 80984 (jsinterp.cpp:3301) This occurred quite a few times with the patch from bug 783393 applied. I haven't tested without it, yet. I was going back and forward between two or more pages in my browser history in the same tab, with the debugger open. The two pages most reliably causing the assertion were: http://htmlpad.org/debugger/ http://htmlpad.org/debugger-with/ I'll see if I can get more precise STR tomorrow. Full stack: http://past.pastebin.mozilla.org/1770631
Ah, DebugScopes::onCompartmentLeaveDebugMode clears the compartment from missingScopes and liveScopes, but not proxiedScopes. I think this is technically fine, since proxiedScopes is a WeakMap and doesn't rely on any onPop* calls, but it would be more regular to clear it out like the others. I'll put up a patch to test in a moment.
Panos, could you apply this patch and tell me if it makes the assert go away?
Assignee: general → luke
Status: NEW → ASSIGNED
I think you nailed it! I can't seem to trigger the assert no matter what I try.
Comment on attachment 654286 [details] [diff] [review] fix Thanks Panos!
Attachment #654286 - Flags: review?(jimb)
Luke, can you construct a regression test for this, knowing what the fix is?
(In reply to Jim Blandy :jimb from comment #5) I'd like to, but to exercise the bug you need to call JS_GetDebugScopeForFrame outside debug mode which is only possible via JS_GetFrameCallObject called from xpc_PrintJSStack (via the xpc_DebuggerKeywordHandler). In theory, I could add a bunch of shell function to call JS_GetFrameCallObject but JS_GetFrameCallObject should be removed (and the one use in XPConnect pulled inside the JS engine where it can be rewritten 10x more cleanly) so I'd rather not.
(In reply to Luke Wagner [:luke] from comment #6) > add a bunch of shell function err, just one, not a bunch :)
I'll push the fix for now to make sure this is in the next aurora uplift. If you think it's important enough, we can subsequently work on a test-case. https://hg.mozilla.org/integration/mozilla-inbound/rev/88d90921b348
(In reply to Luke Wagner [:luke] from comment #6) > (In reply to Jim Blandy :jimb from comment #5) > I'd like to, but to exercise the bug you need to call > JS_GetDebugScopeForFrame outside debug mode which is only possible via > JS_GetFrameCallObject called from xpc_PrintJSStack (via the > xpc_DebuggerKeywordHandler). In theory, I could add a bunch of shell > function to call JS_GetFrameCallObject but JS_GetFrameCallObject should be > removed (and the one use in XPConnect pulled inside the JS engine where it > can be rewritten 10x more cleanly) so I'd rather not. That sounds cool with me. Is there a follow-up bug filed for getting rid of JS_GetFrameCallObject (or something else that will ensure it gets done)?
(In reply to Jim Blandy :jimb from comment #9) Well, JS_GetFrameCallObject is in the same suck-ness class as JS_GetFrameScopeChain which is jsd's primary mechanism for obtaining scopes. Until we switch FB to jsdbg2 and kill jsd we are stuck with them. (Note: Firebug will be calling JS_GetFrameScopeChain with debugMode on, thus not being able to hit this bug.)
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
You need to log in before you can comment on or make changes to this bug.