Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 XUL 0x00000001019ba4c8 JS_Assert + 80 1 XUL 0x00000001019614f1 js::CompartmentChecker::fail(JSCompartment*, JSCompartment*) + 65 2 XUL 0x0000000101847d9b js::CompartmentChecker::check(JSCompartment*) + 101 3 XUL 0x0000000101847dca js::CompartmentChecker::check(JSObject*) + 44 4 XUL 0x000000010184b304 void js::assertSameCompartment<JSFunction*>(JSContext*, JSFunction*) + 61 5 XUL 0x000000010182cc6e JS_DecompileFunction + 207 6 XUL 0x00000001011c20ca jsdScript::GetFunctionSource(nsAString_internal&) + 196 (jsd_xpc.cpp:1323) 7 XUL 0x0000000101667089 NS_InvokeByIndex_P + 576 (xptcinvoke_x86_64_unix.cpp:208) 8 XUL 0x0000000100ee8e07 CallMethodHelper::Invoke() + 105 (xpcwrappednative.cpp:3054) 9 XUL 0x0000000100eeb99d CallMethodHelper::Call() + 283 (xpcwrappednative.cpp:2321)

Comment on attachment 487754 [details] [diff] [review] Possible fix >@@ -1314,20 +1317,24 @@ jsdScript::GetFunctionSource(nsAString & Missing context: . jsdScript::GetFunctionSource(nsAString & aFunctionSource) . { . ASSERT_VALID_EPHEMERAL; . JSContext *cx = JSD_GetDefaultJSContext (mCx); . if (!cx) { > NS_WARNING("No default context !?"); > return NS_ERROR_FAILURE; > } > JSFunction *fun = JSD_GetJSFunction (mCx, mScript); > > JSAutoRequest ar(cx); > > JSString *jsstr; >- if (fun) >+ if (fun) { >+ JSAutoEnterCompartment ac; >+ if (!ac.enter(cx, JS_GetFunctionObject(fun))) >+ return NS_ERROR_FAILURE; > jsstr = JS_DecompileFunction (cx, fun, 4); >- else { >+ } else { > JSScript *script = JSD_GetJSScript (mCx, mScript); >+ js::SwitchToCompartment sc(cx, script->compartment); > jsstr = JS_DecompileScript (cx, script, "ppscript", 4); > } > if (!jsstr) > return NS_ERROR_FAILURE; > > aFunctionSource = > nsDependentString( > reinterpret_cast<PRUnichar*>(JS_GetStringChars(jsstr)), No significant trailing context. Seems like there might be more places that need this kind of invasive surgery. The debugger is running on the default (dumb) context. The debugee (the |this| jsdScript) is running or just runnable on mCx. The only cross-compartment accesses here are from debugger to debugee. Perhaps there's a less invasive way to make this work. Could the compartment code become aware of a debugger compartment, where a context with that compartment is allowed to access other compartments' objects? /be

Comment on attachment 487754 [details] [diff] [review] Possible fix >+ if (fun) { >+ JSAutoEnterCompartment ac; >+ if (!ac.enter(cx, JS_GetFunctionObject(fun))) >+ return NS_ERROR_FAILURE; > jsstr = JS_DecompileFunction (cx, fun, 4); This works. >- else { >+ } else { > JSScript *script = JSD_GetJSScript (mCx, mScript); >+ js::SwitchToCompartment sc(cx, script->compartment); > jsstr = JS_DecompileScript (cx, script, "ppscript", 4); This does not. We'll need to fix this by cloning some logic from JSAutoEnterCompartment, I think.

sayrer, can you post a stack for the 2nd issue.

Did you test this in an opt build? What happens there?

stack below. I tried commenting otu the assertion, but then I just got other asserts in the decompiler, so I think it has to be right. (gdb) bt 10 #0 0x00000001019bad88 in JS_Assert (s=0x101e6b69c "compartment mismatched", file=0x101e6b0d8 "/Users/sayrer/dev/tm/js/src/jscntxtinlines.h", ln=541) at /Users/sayrer/dev/tm/js/src/jsutil.cpp:80 #1 0x0000000101961d97 in js::CompartmentChecker::fail (c1=0x106167400, c2=0x118304200) at jscntxtinlines.h:541 #2 0x000000010184855b in js::CompartmentChecker::check (this=0x7fff5fbf5ff0, c=0x118304200) at jscntxtinlines.h:549 #3 0x000000010184858a in js::CompartmentChecker::check (this=0x7fff5fbf5ff0, obj=0x124bea048) at jscntxtinlines.h:557 #4 0x000000010184b7db in js::CompartmentChecker::CompartmentChecker (this=0x7fff5fbf5ff0, cx=0x12582e2c0) at jscntxtinlines.h:531 #5 0x000000010184baf6 in js::assertSameCompartment<JSScript*> (cx=0x12582e2c0, t1=0x1268bafb0) at jscntxtinlines.h:623 #6 0x000000010182d547 in JS_DecompileScript (cx=0x12582e2c0, script=0x1268bafb0, name=0x101e01165 "ppscript", indent=4) at /Users/sayrer/dev/tm/js/src/jsapi.cpp:4748 #7 0x00000001011c2746 in jsdScript::GetFunctionSource (this=0x1268bab00, aFunctionSource=@0x7fff5fbf6418) at /Users/sayrer/dev/tm/js/jsd/jsd_xpc.cpp:1333 #8 0x00000001016676e5 in NS_InvokeByIndex_P (that=0x1268bab00, methodIndex=15, paramCount=1, params=0x7fff5fbf6350) at /Users/sayrer/dev/tm/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_unix.cpp:208 #9 0x0000000100ee9387 in CallMethodHelper::Invoke (this=0x7fff5fbf6310) at /Users/sayrer/dev/tm/js/src/xpconnect/src/xpcwrappednative.cpp:3054 (More stack frames follow...)

We basically can't use js::SwitchToCompartment outside of the engine. It breaks the cx->scopeChain()->compartment() == cx->compartment invariant. We need an object from the right compartment so we can make a stack frame here.

This is pretty ugly, but under JS_DecompileScript, the fact that the scope chain's compartment doesn't match cx->compartment doesn't actually matter. The problem is that given an arbitrary (really arbitrary since we're coming in from jsd) script, we can't get an object out of it. Some scripts have functions, and we can use those to get a compartment, other scripts have script objects, and those we would be able to use, but then there are also the temporary scripts created by eval and friends, and we can't do anything with those. This patch is the same as the previous one, except that it relaxes the assertion in JS_DecompileScript.

(In reply to comment #3) > Comment on attachment 487754 [details] [diff] [review] > Possible fix > > >+ if (fun) { > >+ JSAutoEnterCompartment ac; > >+ if (!ac.enter(cx, JS_GetFunctionObject(fun))) > >+ return NS_ERROR_FAILURE; > > jsstr = JS_DecompileFunction (cx, fun, 4); > > This works. > > >- else { > >+ } else { > > JSScript *script = JSD_GetJSScript (mCx, mScript); > >+ js::SwitchToCompartment sc(cx, script->compartment); > > jsstr = JS_DecompileScript (cx, script, "ppscript", 4); > > This does not. We'll need to fix this by cloning some logic from > JSAutoEnterCompartment, I think. This comment does not appear to have made its way into the code, and I believe caused #614131 . Attaching proposed patch.

Should this block beta8? or move to the next one?

Comment on attachment 497469 [details] [diff] [review] Patch to incorporate comment mentioned. This doesn't actually work, in certain cases the script object doesn't exist. Patch which accounts for this forthcoming.

(In reply to comment #13) > Should this block beta8? or move to the next one? In my opinion, this should not block beta8, but should block beta9. Single-stepping doesn't work in b8 anyway, so JSD (read: firebug) is largely useless unless methodjit is disabled. b9 will have single-stepping again -- or really, single-stepping for JM for the first time. See bug 610793.

This patch adds an API to do a cross compartment call given only a JSScript with no script object.

Comment on attachment 497587 [details] [diff] [review] Proposed fix-fix v1 Patch merged in to bug 614131 .

We can get the object from script and enter with that?

The blocking flag needs to be changed on this one - still set to beta7.

Re-marking as fixed. bug 614131 can track the remaining work.