Running marionette tests on debug emulator build crashes with a compartment mismatch error. https://tbpl.mozilla.org/php/getParsedLog.php?id=29907361&tree=Pine&full=1 The interesting thing here is that sending a single message works but sending multiple ones doesn't: INFO - 10-31 01:37:16.624 45 45 I Gecko : MARIONETTE TEST RESULT:TEST-PASS | test_outgoing.js | the messages got from onsent event and request result must be the same - 1383197833446 should equal 1383197833446 22:39:02 INFO - 10-31 01:37:16.634 45 45 I Gecko : MARIONETTE LOG: INFO: Done! 22:39:02 INFO - 10-31 01:37:16.863 45 45 I Gecko : MARIONETTE LOG: INFO: Testing sending message to multiple receivers: INFO - 10-31 01:37:16.883 45 45 F MOZ_CRASH: Hit MOZ_CRASH() at ../../../gecko/js/src/jscntxtinlines.h:40 We don't have a stack :(

(In reply to Gregor Wagner [:gwagner] from comment #0) > We don't have a stack :( Bug 866937?

bholley/mrbkap, something you can investigate?

To reproduce locally, you need to download a debug emulator from pine (assuming you don't want to build one yourself) at e.g., https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/pine-generic-debug/20131101113220/ and extract it to $EMULATOR_DIR Then, download the corresponding tests.zip package at the same url and extract it to $TESTS_DIR cd $TESTS_DIR/marionette python setup.py develop cd marionette python runtests.py --emulator arm --homedir $EMULATOR_DIR --type b2g ../tests/testing/marionette/client/marionette/tests/unit-tests.ini You may want to do the above inside a Python virtualenv (https://developer.mozilla.org/en-US/docs/Python/Virtualenv) to avoid Python package problems.

Compartment mismatches are generally diagnosable from a stack, and if not, definitely from gdb. I'm happy to look at stacks and help someone debug if anything turns out to be tricky, but my bandwidth is limited, and it's not yet clear to me that my particular expertise is needed here.

Also, let's be safe here given that this is a compartment mismatch.

I think I see the problem. Note also bug 934000 that we should fix at the same time.

Re-setting core-security since I suspect it may have been removed by accident.

(In reply to Andrew Overholt [:overholt] from comment #7) > Re-setting core-security since I suspect it may have been removed by > accident. Vicamo, do you know what caused you to open up the bug? Doing so is a pretty big security hazard, so it's pretty important to avoid doing so in the future.

Program received signal SIGSEGV, Segmentation fault. 0xb5750710 in js::CompartmentChecker::fail (c1=<optimized out>, c2=<optimized out>) at ../../../js/src/jscntxtinlines.h:40 40 MOZ_CRASH(); (gdb) bt #0 0xb5750710 in js::CompartmentChecker::fail (c1=<optimized out>, c2=<optimized out>) at ../../../js/src/jscntxtinlines.h:40 #1 0xb58ee354 in check (c=<optimized out>, this=<optimized out>) at ../../../js/src/jscntxtinlines.h:61 #2 js::CompartmentChecker::check (this=<optimized out>, c=<optimized out>) at ../../../js/src/jscntxtinlines.h:56 #3 0xb58ee380 in check (obj=<optimized out>, this=0xbea4d360) at ../../../js/src/jscntxtinlines.h:72 #4 js::assertSameCompartment<JS::Rooted<JSObject*> > (cx=0xae82e090, t1=<optimized out>) at ../../../js/src/jscntxtinlines.h:147 #5 0xb58f95e8 in assertSameCompartment<JS::Rooted<JSObject*> > (t1=..., cx=0xae82e090) at ../../../js/src/jscntxtinlines.h:146 #6 JS_IsArrayObject (cx=0xae82e090, objArg=<optimized out>) at ../../../js/src/jsapi.cpp:3819 #7 0xb4df783c in Delete (aRequest=0xbea4d4e8, aParam=..., this=0xac9c4400) at ../../../../dom/mobilemessage/src/MobileMessageManager.cpp:344 #8 mozilla::dom::MobileMessageManager::Delete (this=0xac9c4400, aParam=..., aRequest=0xbea4d4e8) at ../../../../dom/mobilemessage/src/MobileMessageManager.cpp:323 #9 0xb469c356 in NS_InvokeByIndex (that=0xac9c4428, methodIndex=20, paramCount=<optimized out>, params=<optimized out>) at ../../../../../../../xpcom/reflect/xptcall/src/md/unix/xptcinvoke_arm.cpp:164 #10 0xb4cff370 in Invoke (this=0xbea4d4b0) at ../../../../js/xpconnect/src/XPCWrappedNative.cpp:2567 #11 CallMethodHelper::Call (this=0xbea4d4b0) at ../../../../js/xpconnect/src/XPCWrappedNative.cpp:1907 #12 0xb4cffe2c in XPCWrappedNative::CallMethod (ccx=..., mode=XPCWrappedNative::CALL_METHOD) at ../../../../js/xpconnect/src/XPCWrappedNative.cpp:1873 #13 0xb4d00236 in XPC_WN_CallMethod (cx=0xb6a63bc0, argc=1, vp=<optimized out>) at ../../../../js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1301 #14 0xb59aef08 in js::CallJSNative (cx=0xb6a63bc0, native=0xb4d00141 <XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)>, args=...) at ../../../js/src/jscntxtinlines.h:220 #15 0xb59d69e2 in js::Invoke (cx=0xb6a63bc0, args=..., construct=js::NO_CONSTRUCT) at ../../../js/src/vm/Interpreter.cpp:463 #16 0xb59cd42c in Interpret (cx=0xb6a63bc0, state=...) at ../../../js/src/vm/Interpreter.cpp:2505 #17 0xb59d53ec in RunScript (state=..., cx=0xb6a63bc0) at ../../../js/src/vm/Interpreter.cpp:420 #18 js::RunScript (cx=0xb6a63bc0, state=...) at ../../../js/src/vm/Interpreter.cpp:387 #19 0xb59d6990 in js::Invoke (cx=0xb6a63bc0, args=..., construct=js::NO_CONSTRUCT) at ../../../js/src/vm/Interpreter.cpp:482 #20 0xb59d6f2a in js::Invoke (cx=0xb6a63bc0, thisv=<optimized out>, fval=..., argc=1, argv=0xb20210d8, rval=...) at ../../../js/src/vm/Interpreter.cpp:513 #21 0xb5951c64 in js::DirectProxyHandler::call (this=<optimized out>, cx=<optimized out>, proxy=<optimized out>, args=...) at ../../../js/src/jsproxy.cpp:467 #22 0xb5982e8e in js::CrossCompartmentWrapper::call (this=0xb6552b04, cx=0xb6a63bc0, wrapper=..., args=...) at ../../../js/src/jswrapper.cpp:457 #23 0xb597095e in js::Proxy::call (cx=<optimized out>, proxy=..., args=...) at ../../../js/src/jsproxy.cpp:2658 #24 0xb5970a04 in proxy_Call (cx=0xb6a63bc0, argc=<optimized out>, vp=<optimized out>) at ../../../js/src/jsproxy.cpp:3066 #25 0xb59aef08 in js::CallJSNative (cx=0xb6a63bc0, native=0xb5970985 <proxy_Call(JSContext*, unsigned int, JS::Value*)>, args=...) at ../../../js/src/jscntxtinlines.h:220 #26 0xb59d6a90 in js::Invoke (cx=0xb6a63bc0, args=..., construct=js::NO_CONSTRUCT) at ../../../js/src/vm/Interpreter.cpp:456 #27 0xb59cd42c in Interpret (cx=0xb6a63bc0, state=...) at ../../../js/src/vm/Interpreter.cpp:2505 #28 0xb59d53ec in RunScript (state=..., cx=0xb6a63bc0) at ../../../js/src/vm/Interpreter.cpp:420 #29 js::RunScript (cx=0xb6a63bc0, state=...) at ../../../js/src/vm/Interpreter.cpp:387 #30 0xb59d6990 in js::Invoke (cx=0xb6a63bc0, args=..., construct=js::NO_CONSTRUCT) at ../../../js/src/vm/Interpreter.cpp:482 #31 0xb592cc9e in js::CallOrConstructBoundFunction (cx=<optimized out>, argc=<optimized out>, vp=0xbea4f330) at ../../../js/src/jsfun.cpp:1274 #32 0xb59aef08 in js::CallJSNative (cx=0xb6a63bc0, native=0xb592cb09 <js::CallOrConstructBoundFunction(JSContext*, unsigned int, JS::Value*)>, args=...) at ../../../js/src/jscntxtinlines.h:220

remote: https://hg.mozilla.org/integration/b2g-inbound/rev/ddf665aa22b3 remote: https://hg.mozilla.org/integration/b2g-inbound/rev/223af50b7080

https://hg.mozilla.org/mozilla-central/rev/ddf665aa22b3 https://hg.mozilla.org/mozilla-central/rev/223af50b7080

From a quick code review these all appear to be affected.

Please nominate this for b2g26/b2g18 uplift.

The situation on b2g18/26 is much worse than for 1.3. In particular, bug 854326 actually came really close to fixing this altogether (missing only the two patches needed here). It'll be a bit before I have the time to backport this patch.

I'm still building this, but I have to run. Optimistically requesting review.

https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/a1738189c5bf https://hg.mozilla.org/releases/mozilla-b2g18/rev/2075e0864e98

Al - Do you know if this bug impacts Desktop and Android? Should we consider taking this for ESR24?

I have no knowledge of the details of this bug. At this point, I don't expect we'll take it.

From the patch I take it that this does not impact desktop. I'm not clear whether this impacts Android. Blake - Do you have any guidance on whether this bug impacts products other than B2G?

I just confirmed with blassey on IRC that we don't build this for Android. Therefore, I believe that this bug only applies to b2g.

Based on comment 25, marking as esr24-.