609066 - nsIJetpack.registerReceiver throws NS_ERROR_ILLEGAL_VALUE in e10s tests on trunk nightly

Status: VERIFIED FIXED

(Core :: General, defect)

Description

[Myk Melez [:myk] [@mykmelez]]

On a Firefox 4 trunk nightly build, a bunch of the new e10s tests fail, apparently due to NS_ERROR_ILLEGAL_VALUE exceptions thrown by nsIJetpack.registerReceiver.  The tests work on Firefox 4.0b6.

Brian, Atul: any ideas what might be going on here?  In particular, it would be useful to know if this is an issue in the SDK or a regression in the platform.

Here's a sample failure:

--------------------------------------------------------------------------------
error: TEST FAILED: test-e10s-porting.runE10SCompatibleTestSuites (exception)
error: An exception occurred.
Traceback (most recent call last):
  File "resource://jetpack-core-jetpack-core-lib/timer.js", line 64, in notifyOnTimeout
    this._callback.apply(null, this._params);
  File "resource://jetpack-core-jetpack-core-lib/unit-test.js", line 223, in anonymous
    timer.setTimeout(function() { onDone(self); }, 0);
  File "resource://jetpack-core-jetpack-core-lib/unit-test.js", line 248, in runNextTest
    self.start({test: test, onDone: runNextTest});
  File "resource://jetpack-core-jetpack-core-lib/unit-test.js", line 266, in start
    this.test.testFunction(this);
  File "resource://jetpack-core-jetpack-core-lib/unit-test-finder.js", line 57, in runTest
    test(runner);
  File "resource://jetpack-core-jetpack-core-tests/test-e10s-porting.js", line 42, in anonymous
    finder.findTests(function(tests) {
  File "resource://jetpack-core-jetpack-core-lib/unit-test-finder.js", line 100, in findTests
    var process = require("e10s").createProcess();
  File "resource://jetpack-core-jetpack-core-lib/e10s.js", line 106, in createProcess
    ['log', 'debug', 'info', 'warn', 'error'].forEach(function(method) {
  File "resource://jetpack-core-jetpack-core-lib/e10s.js", line 107, in anonymous
    process.registerReceiver("console:" + method, function(name, args) {
  File "resource://jetpack-core-jetpack-core-lib/e10s.js", line 50, in anonymous
    process.registerReceiver(name, errors.catchAndLog(cb));
[Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIJetpack.registerReceiver]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: resource://jetpack-core-jetpack-core-lib/securable-module.js -> resource://jetpack-core-jetpack-core-lib/securable-module.js -> resource://jetpack-core-jetpack-core-lib/e10s.js :: anonymous :: line 50"  data: no]
--------------------------------------------------------------------------------

Comment 1

[Benjamin Smedberg]

532   if (!JSVAL_IS_OBJECT(receiver) ||
533       !JS_ObjectIsFunction(cx, JSVAL_TO_OBJECT(receiver)))
534     return NS_ERROR_INVALID_ARG;

That's the only way you can get NS_ERROR_ILLEGAL_VALUE (INVALID_ARG and ILLEGAL_VALUE are the same thing).

Comment 2

[Benjamin Smedberg]

The code that's failing is:
http://github.com/mozilla/addon-sdk/blob/master/packages/jetpack-core/lib/e10s.js#L50

Called from http://github.com/mozilla/addon-sdk/blob/master/packages/jetpack-core/lib/e10s.js#L106

receiver is a js::FunctionProxyClass. Should JS_ObjectIsFunction be false for js::FunctionProxyClass?

Atul/Brian, do we know why xpconnect would be creating a proxy for this function? Is this code running in a sandbox which doesn't use the normal chrome compartment?

>	xul.dll!mozilla::jetpack::JetpackActorCommon::RegisterReceiver(cx=0x03489a60, messageName={...}, receiver=0xffff00070c91e410)  Line 534	C++
 	xul.dll!mozilla::jetpack::JetpackParent::RegisterReceiver(aMessageName={...}, aReceiver=0xffff00070c91e410)  Line 115	C++
 	xul.dll!NS_InvokeByIndex_P(that=0x10a431fc, methodIndex=0x00000004, paramCount=0x00000002, params=0x003da088)  Line 103	C++
 	xul.dll!XPC_WN_CallMethod(cx=0x03489a60, argc=0x00000002, vp=0x045a0618)  Line 1589	C++
 	mozjs.dll!js::Interpret(cx=0x03489a60, entryFrame=0x045a0598, inlineCallCount=0x00000001, interpMode=JSINTERP_NORMAL)  Line 4746	C++
 	mozjs.dll!js::RunScript(cx=0x03489a60, script=0x0c596d80, fp=0x045a0598)  Line 665	C++
 	mozjs.dll!js::Invoke(cx=0x03489a60, argsRef={...}, flags=0x00002000)  Line 768	C++
 	mozjs.dll!js::InvokeSessionGuard::invoke(cx=0x03489a60)  Line 562	C++
 	mozjs.dll!array_extra(cx=, mode=, argc=, vp=)  Line 2723	C++
 	mozjs.dll!array_forEach(cx=0x03489a60, argc=0x00000001, vp=0x045a0540)  Line 2780	C++
 	mozjs.dll!js::Interpret(cx=0x03489a60, entryFrame=0x045a04f0, inlineCallCount=0x00000000, interpMode=JSINTERP_NORMAL)  Line 4746	C++
 	mozjs.dll!js::RunScript(cx=0x03489a60, script=0x0ca0c400, fp=0x045a04f0)  Line 665	C++
 	mozjs.dll!js::Invoke(cx=0x03489a60, argsRef={...}, flags=0x00004000)  Line 768	C++
 	mozjs.dll!js::ExternalInvoke(cx=0x03489a60, thisv={...}, fval={...}, argc=0x00000000, argv=0x045a0488, rval=0x003db0c0)  Line 881	C++
 	mozjs.dll!js::JSProxyHandler::call(cx=0x03489a60, proxy=0x0c4cd7b8, argc=0x00000000, vp=0x045a0478)  Line 245	C++
 	mozjs.dll!JSCrossCompartmentWrapper::call(cx=0x03489a60, wrapper=0x0c4cd7b8, argc=0x00000000, vp=0x045a0478)  Line 593	C++
 	mozjs.dll!js::JSProxy::call(cx=0x00000000, proxy=0x00000000, argc=0x00000000, vp=0x045a0478)  Line 788	C++
 	mozjs.dll!js::proxy_Call(cx=0x03489a60, argc=0x00000000, vp=0x045a0478)  Line 1013	C++
 	mozjs.dll!js::Invoke(cx=0x03489a60, argsRef={...}, flags=0x00000000)  Line 701	C++
 	mozjs.dll!js::Interpret(cx=0x03489a60, entryFrame=0x045a0410, inlineCallCount=0x00000000, interpMode=JSINTERP_NORMAL)  Line 4756	C++
 	mozjs.dll!js::RunScript(cx=0x03489a60, script=0x04ab5c20, fp=0x045a0410)  Line 665	C++
 	mozjs.dll!js::Invoke(cx=0x03489a60, argsRef={...}, flags=0x00000000)  Line 768	C++
 	mozjs.dll!js::ExternalInvoke(cx=0x03489a60, thisv={...}, fval={...}, argc=0x00000001, argv=0x045a03a0, rval=0x003db840)  Line 881	C++
 	mozjs.dll!js::JSProxyHandler::call(cx=0x03489a60, proxy=0x0c907548, argc=0x00000001, vp=0x045a0390)  Line 245	C++
 	mozjs.dll!JSCrossCompartmentWrapper::call(cx=0x03489a60, wrapper=0x0c907548, argc=0x00000001, vp=0x045a0390)  Line 593	C++
 	mozjs.dll!js::JSProxy::call(cx=0x00000000, proxy=0x00000000, argc=0x00000001, vp=0x045a0390)  Line 788	C++
 	mozjs.dll!js::proxy_Call(cx=0x03489a60, argc=0x00000001, vp=0x045a0390)  Line 1013	C++
 	mozjs.dll!js::Invoke(cx=0x03489a60, argsRef={...}, flags=0x00000000)  Line 701	C++
 	mozjs.dll!js::Interpret(cx=0x03489a60, entryFrame=0x045a0330, inlineCallCount=0x00000000, interpMode=JSINTERP_NORMAL)  Line 4756	C++
 	mozjs.dll!js::RunScript(cx=0x03489a60, script=0x0c8e41c0, fp=0x045a0330)  Line 665	C++
 	mozjs.dll!js::Invoke(cx=0x03489a60, argsRef={...}, flags=0x00000000)  Line 768	C++
 	mozjs.dll!js::ExternalInvoke(cx=0x03489a60, thisv={...}, fval={...}, argc=0x00000001, argv=0x045a02c0, rval=0x003dbfc0)  Line 881	C++
 	mozjs.dll!js::JSProxyHandler::call(cx=0x03489a60, proxy=0x0c64f820, argc=0x00000001, vp=0x045a02b0)  Line 245	C++
 	mozjs.dll!JSCrossCompartmentWrapper::call(cx=0x03489a60, wrapper=0x0c64f820, argc=0x00000001, vp=0x045a02b0)  Line 593	C++
 	mozjs.dll!js::JSProxy::call(cx=0x00000000, proxy=0x00000000, argc=0x00000001, vp=0x045a02b0)  Line 788	C++
 	mozjs.dll!js::proxy_Call(cx=0x03489a60, argc=0x00000001, vp=0x045a02b0)  Line 1013	C++
 	mozjs.dll!js::Invoke(cx=0x03489a60, argsRef={...}, flags=0x00000000)  Line 701	C++
 	mozjs.dll!js::Interpret(cx=0x03489a60, entryFrame=0x045a0280, inlineCallCount=0x00000000, interpMode=JSINTERP_NORMAL)  Line 4756	C++
 	mozjs.dll!js::RunScript(cx=0x03489a60, script=0x0c28ae80, fp=0x045a0280)  Line 665	C++
 	mozjs.dll!js::Invoke(cx=0x03489a60, argsRef={...}, flags=0x00000000)  Line 768	C++
 	mozjs.dll!js::ExternalInvoke(cx=0x03489a60, thisv={...}, fval={...}, argc=0x00000001, argv=0x045a0210, rval=0x003dc740)  Line 881	C++
 	mozjs.dll!js::JSProxyHandler::call(cx=0x03489a60, proxy=0x10c192d8, argc=0x00000001, vp=0x045a0200)  Line 245	C++
 	mozjs.dll!JSCrossCompartmentWrapper::call(cx=0x03489a60, wrapper=0x10c192d8, argc=0x00000001, vp=0x045a0200)  Line 593	C++
 	mozjs.dll!js::JSProxy::call(cx=0x00000000, proxy=0x00000000, argc=0x00000001, vp=0x045a0200)  Line 788	C++
 	mozjs.dll!js::proxy_Call(cx=0x03489a60, argc=0x00000001, vp=0x045a0200)  Line 1013	C++
 	mozjs.dll!js::Invoke(cx=0x03489a60, argsRef={...}, flags=0x00000000)  Line 701	C++
 	mozjs.dll!js::Interpret(cx=0x03489a60, entryFrame=0x045a0138, inlineCallCount=0x00000002, interpMode=JSINTERP_NORMAL)  Line 4756	C++
 	mozjs.dll!js::RunScript(cx=0x03489a60, script=0x0c505d80, fp=0x045a0138)  Line 665	C++
 	mozjs.dll!js::Invoke(cx=0x03489a60, argsRef={...}, flags=0x00000000)  Line 768	C++
 	mozjs.dll!js_fun_apply(cx=0x03489a60, argc=0x00000002, vp=0x045a0108)  Line 2341	C++
 	mozjs.dll!js::Invoke(cx=0x03489a60, argsRef={...}, flags=0x00000000)  Line 708	C++
 	mozjs.dll!js::ExternalInvoke(cx=0x03489a60, thisv={...}, fval={...}, argc=0x00000002, argv=0x045a00a8, rval=0x003dcf80)  Line 881	C++
 	mozjs.dll!js::JSProxyHandler::call(cx=0x03489a60, proxy=0x0c4b8208, argc=0x00000002, vp=0x045a0098)  Line 245	C++
 	mozjs.dll!JSCrossCompartmentWrapper::call(cx=0x03489a60, wrapper=0x0c4b8208, argc=0x00000002, vp=0x045a0098)  Line 593	C++
 	mozjs.dll!js::JSProxy::call(cx=0x00000000, proxy=0x00000000, argc=0x00000002, vp=0x045a0098)  Line 788	C++
 	mozjs.dll!js::proxy_Call(cx=0x03489a60, argc=0x00000002, vp=0x045a0098)  Line 1013	C++
 	mozjs.dll!js::Invoke(cx=0x03489a60, argsRef={...}, flags=0x00000000)  Line 701	C++
 	mozjs.dll!js::Interpret(cx=0x03489a60, entryFrame=0x045a0068, inlineCallCount=0x00000000, interpMode=JSINTERP_NORMAL)  Line 4756	C++
 	mozjs.dll!js::RunScript(cx=0x03489a60, script=0x0c509100, fp=0x045a0068)  Line 665	C++
 	mozjs.dll!js::Invoke(cx=0x03489a60, argsRef={...}, flags=0x00000000)  Line 768	C++
 	mozjs.dll!js::ExternalInvoke(cx=0x03489a60, thisv={...}, fval={...}, argc=0x00000001, argv=0x003dd830, rval=0x003dd7c8)  Line 881	C++
 	mozjs.dll!JS_CallFunctionValue(cx=0x03489a60, obj=0x10c58360, fval=0xffff00070c4b6380, argc=0x00000001, argv=0x003dd830, rval=0x003dd7c8)  Line 4896	C++
 	xul.dll!nsXPCWrappedJSClass::CallMethod(wrapper=0x0c8bbe40, methodIndex=0x0003, info=0x03a1afa0, nativeParams=0x003dda04)  Line 1694	C++
 	xul.dll!nsXPCWrappedJS::CallMethod(methodIndex=0x0003, info=0x03a1afa0, params=0x003dda04)  Line 577	C++
 	xul.dll!PrepareAndDispatch(self=0x10e71c90, methodIndex=0x00000003, args=0x003ddabc, stackBytesToPop=0x003ddaac)  Line 114	C++
 	xul.dll!SharedStub()  Line 142	C++
 	xul.dll!nsTimerImpl::Fire()  Line 429	C++

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to comment #2)
> receiver is a js::FunctionProxyClass. Should JS_ObjectIsFunction be false for
> js::FunctionProxyClass?

I think it should. The way things are written right now, JS_ObjectIsFunction guarantees JS_ValueToFunction will return non-null. What we really need is a JS_IsCallable API. For the moment, you can either break encapsulation and use obj->isCallable() or JS_TypeOfValue(cx, obj) == JSTYPE_FUNCTION.

Oh, btw, you want !JSVAL_IS_OBJECT(receiver) => JSVAL_IS_PRIMITIVE(receiver) to also deal with null.

> Atul/Brian, do we know why xpconnect would be creating a proxy for this
> function? Is this code running in a sandbox which doesn't use the normal chrome
> compartment?

Sandboxes are always in their own distinct compartments.

Comment 4

[Benjamin Smedberg]

Attachment: Test for sandboxed receivers, rev. 1

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 489176 [details] [diff] [review]
Test for sandboxed receivers, rev. 1

Does ReceiverCommon need the same treatment? r=me with that looked into.

Comment 6

[Brendan Eich [:brendan]]

(In reply to comment #3)
> (In reply to comment #2)
> > receiver is a js::FunctionProxyClass. Should JS_ObjectIsFunction be false for
> > js::FunctionProxyClass?
> 
> I think it should. The way things are written right now, JS_ObjectIsFunction
> guarantees JS_ValueToFunction will return non-null.

Agreed. JS API "Function" is concrete compared to typeof x == "function", which covers proxies and native callablesl (but not regexps, which [bug is on file] should not be callable).

> What we really need is a
> JS_IsCallable API. For the moment, you can either break encapsulation and use
> obj->isCallable() or JS_TypeOfValue(cx, obj) == JSTYPE_FUNCTION.

Bug on file on this?

/be

Comment 7

[Myk Melez [:myk] [@mykmelez]]

The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product.

To filter bugmail related to this change, filter on the word "looptid".

Comment 8

[Myk Melez [:myk] [@mykmelez]]

Moving this to a more appropriate product/component.

Comment 9

[Myk Melez [:myk] [@mykmelez]]

We should get this in for Firefox 4.0b8 so we can use the Add-on SDK's e10s framework with that version of Firefox.

Comment 11

[Benjamin Smedberg]

The tryserver tests for this are hanging (but not locally on any platform). I'll attach the patch, but I don't know what's going on. I don't think I can block beta8 on this, but I'll keep pushing at it.

Comment 12

[Benjamin Smedberg]

I don't know why, but altering the test slightly to actually require a process roundtrip fixed the issues, so this has landed.

http://hg.mozilla.org/mozilla-central/rev/b5c6ae71b2eb

Comment 13

[Myk Melez [:myk] [@mykmelez]]

Testing against a tip build confirms that the Add-on SDK's e10s tests no longer fail with this change.