Last Comment Bug 784706 - Assertion failure: CanUseDebugScopeMaps(cx), at js/src/vm/ScopeObject.cpp
: Assertion failure: CanUseDebugScopeMaps(cx), at js/src/vm/ScopeObject.cpp
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86 Mac OS X
: -- normal (vote)
: mozilla17
Assigned To: Luke Wagner [:luke]
:
: Jason Orendorff [:jorendorff]
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-22 09:39 PDT by Panos Astithas [:past]
Modified: 2012-08-24 20:02 PDT (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
fix (1.73 KB, patch)
2012-08-22 11:24 PDT, Luke Wagner [:luke]
jimb: review+
Details | Diff | Splinter Review

Description Panos Astithas [:past] 2012-08-22 09:39:32 PDT
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
Comment 1 Luke Wagner [:luke] 2012-08-22 11:20:54 PDT
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.
Comment 2 Luke Wagner [:luke] 2012-08-22 11:24:52 PDT
Created attachment 654286 [details] [diff] [review]
fix

Panos, could you apply this patch and tell me if it makes the assert go away?
Comment 3 Panos Astithas [:past] 2012-08-23 02:10:21 PDT
I think you nailed it! I can't seem to trigger the assert no matter what I try.
Comment 4 Luke Wagner [:luke] 2012-08-23 09:00:31 PDT
Comment on attachment 654286 [details] [diff] [review]
fix

Thanks Panos!
Comment 5 Jim Blandy :jimb 2012-08-23 20:03:50 PDT
Luke, can you construct a regression test for this, knowing what the fix is?
Comment 6 Luke Wagner [:luke] 2012-08-24 09:35:50 PDT
(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.
Comment 7 Luke Wagner [:luke] 2012-08-24 09:36:52 PDT
(In reply to Luke Wagner [:luke] from comment #6)
> add a bunch of shell function

err, just one, not a bunch :)
Comment 8 Luke Wagner [:luke] 2012-08-24 09:46:24 PDT
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
Comment 9 Jim Blandy :jimb 2012-08-24 09:53:38 PDT
(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)?
Comment 10 Luke Wagner [:luke] 2012-08-24 10:02:11 PDT
(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.)
Comment 11 Ryan VanderMeulen [:RyanVM] 2012-08-24 20:02:23 PDT
https://hg.mozilla.org/mozilla-central/rev/88d90921b348

Note You need to log in before you can comment on or make changes to this bug.