Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Compartment mismatch in JetPack 'test-content-proxy.testTypedArrays'

RESOLVED FIXED in mozilla14

Status

()

Core
DOM
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Ms2ger, Assigned: Ms2ger)

Tracking

Trunk
mozilla14
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Assignee)

Description

5 years ago
The test at

https://github.com/mozilla/addon-sdk/blob/master/packages/api-utils/tests/test-content-proxy.js#L743

hits a compartment mismatch; see

https://tbpl.mozilla.org/?noignore=1&jobname=jetpack

Hoping for smart people who can tell me what I need to do here.

Updated

5 years ago
Blocks: 736699
crash stack?

Also, when did this start happening?
(In reply to Bobby Holley (:bholley) from comment #1)
> crash stack?
> 
> Also, when did this start happening?

This push had JP tests as permaorange-but-really-greenish: https://tbpl.mozilla.org/?noignore=1&jobname=jetpack&rev=e5f6caa40409

The next push after that turned them permared-but-really-orangish: https://tbpl.mozilla.org/?noignore=1&jobname=jetpack&rev=ee56787a20fb
The unit test isn't perfect, may be too agressive on its checks.


Jetpack (over) use sandboxes. So in this particular test case we have 3 sandboxes and the content document:
- 1 chrome sandbox hosting the test module (not really important here)
- 1 content document
- 1 content sandbox with same principal than the document, hosting the proxy code
- 1 another similar sandbox, hosting the content script

It looks like we are hitting some wrapper behavior difference. I can't exactly tell if the new behavior is expected or not.
Here is a minimal (scratchpad) testcase that highlights what changed.
let Cu = Components.utils;

// First content sandbox that simulates the proxy code
let s1 = Cu.Sandbox(content, {wantXrays:true});
function foo(doc) {
  let canvas = doc.createElement("canvas");
  let context = canvas.getContext("2d");
  let proxy = context.getImageData(0,0, 1, 1);
  return {
    proxy: proxy,
    get data () proxy.data
  };
}
Cu.evalInSandbox(foo, s1);

// Second content sandbox that simulates the content script code
let s2 = Cu.Sandbox(content, {wantXrays:true});
function bar() {
  // Here, on nightly, it is different.
  // I assume we get some king of wrappers whereas we didn't get any visible wrapper before.
  return obj.proxy.data === obj.data;
}

// Call first sandbox code and give the result back to the second one
s2.obj = s1.foo(content.document);
let rv = Cu.evalInSandbox("("+bar+"())", s2)

// `rv` was true, now it is false
Cu.reportError(">> " + rv);
(In reply to Alexandre Poirot (:ochameau) from comment #3)
> The unit test isn't perfect, may be too agressive on its checks.

Possibly, but it shouldn't matter - JS should never be able to trigger a compartment mismatch. So it's almost certainly a bug in spidermonkey or XPConnect.

If somebody posts a reduced testcase that hits the cross-compartment assertion, I'll fire up gdb to see what's going on.
Created attachment 607493 [details]
Backtrace

(In reply to Bobby Holley (:bholley) from comment #4)
> If somebody posts a reduced testcase that hits the cross-compartment
> assertion, I'll fire up gdb to see what's going on.

The script inlined in comment 3 is such testcase. It hits this assertion.
Here is the backtrace while running it manually in scratchpad.
(Assignee)

Comment 6

5 years ago
static JSBool
nsIDOMImageData_GetData(JSContext *cx, JSObject *obj, jsid id, jsval *vp)
{
    XPC_QS_ASSERT_CONTEXT_OK(cx);
    nsIDOMImageData *self;
    xpc_qsSelfRef selfref;
    if (!xpc_qsUnwrapThis(cx, obj, &self, &selfref.ptr, vp, nsnull, true))
        return JS_FALSE;
    self->GetData(vp);
    return JS_TRUE;
}

After the call, obj and *vp aren't in the same compartment (according to the bt).
That's because GetData needs to JS_WrapValue the retval, I like told you on IRC on Saturday.
(Assignee)

Comment 8

5 years ago
Created attachment 607709 [details] [diff] [review]
Patch v1

Something like this, perhaps
Assignee: nobody → Ms2ger
Status: NEW → ASSIGNED
Attachment #607709 - Flags: review?(bobbyholley+bmo)
Attachment #607709 - Flags: review?(bobbyholley+bmo) → review+
https://hg.mozilla.org/mozilla-central/rev/ab2ff3b5611f

Yeah, I did want to push it, but I was still at work then ;)
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla14
You need to log in before you can comment on or make changes to this bug.