766641 - sporadic assert when running mochitests: "Assertion failure: !AccessCheck::callerIsChrome(), at ../../../../mozilla/js/xpconnect/wrappers/XrayWrapper.cpp:770"

Status: RESOLVED INACTIVE

(Core :: XPConnect, defect)

Description

[Daniel Holbert [:dholbert]]

When doing a local mochitest run, I sporadically hit this JS assertion-failure:
> Assertion failure: !AccessCheck::callerIsChrome(), at ../../../../mozilla/js/xpconnect/wrappers/XrayWrapper.cpp:770

This was at the end of a targeted run of a local layout/CSS mochitest (not yet checked in), which I ran as follows:
TEST_PATH=layout/style/test/test_flexbox_layout.html make mochitest-plain

When I ran the command again a few times, I didn't get the assertion-failure -- so this appears to be sporadic.  So, I can't really dig deeper, since I've only hit it once -- still, I figured it merited a bug.

The mozilla-central tree I'm using is based off of this cset from yesterday: http://hg.mozilla.org/mozilla-central/rev/1f7af949b280

Comment 1

[Bobby Holley (:bholley)]

Those asserts landed on m-c yesterday, so this makes sense.

If you can get a backtrace or consistent STR, it would be much appreciated.

Comment 2

[Eitan Isaacson [:eeejay]]

Attachment: Stack trace

Is this useful?

Comment 3

[Bobby Holley (:bholley)]

(In reply to Eitan Isaacson [:eeejay] from comment #2)
> Created attachment 635088 [details]
> Stack trace
> 
> Is this useful?

Yes!

So the thing we're unwrapping is a XOW (PARTIALLY_TRANSPARENT), which presumably means that we're running content code here. If we're not, then somehow chrome got a partially transparent wrapper, which is a bug. Assuming we are, this assert means that we're unwrapping the XOW with a chrome principal, which is bad.

STR would be very helpful here.

Comment 4

[Dana Keeler (she/her) [:keeler]]

I might have STR:
1. Navigate to todoist.com
2. Click "Watch a Video"
3. (If you don't hit the assertion after a second or two, maybe try Ctrl+Shift+I and click on the video area that comes up)

Comment 5

[Bobby Holley (:bholley)]

(In reply to David Keeler from comment #4)
> I might have STR:
> 1. Navigate to todoist.com
> 2. Click "Watch a Video"
> 3. (If you don't hit the assertion after a second or two, maybe try
> Ctrl+Shift+I and click on the video area that comes up)

Nice! I reproduced it in a debugger. Looking at it now.

Comment 6

[Bobby Holley (:bholley)]

The stack I get from the STR in comment 4 is different than the one that eeejay attached. So this can probably be triggered in multiple ways.

The issue with the comment 4 STR is as follows:
* We have a chrome scope and content scopes A and B.
* We have an Xray wrapper from chrome to content, and we call Aobj instanceof Bobj from chrome.
* We hit the Xray wrapper for B, and bounce directly to CrossCompartmentWrapper::HasInstance. This enters B's compartment, and rewraps Aobj in the scope of B, giving us a XOW. But note that we've now entered a content compartment without pushing a principal, since we used XrayWrapper and not a SJOW.
* Because of the lack of a pushed principal, SetSubjectPrincipal sometimes returns System.

So really, HasInstance violates the contract of XrayWrapper by entering the callee's compartment. But I don't think it's worth worrying too much about, since AFAIK script can't run in a hasInstance hook.

This variant of the assert will just go away when bug 754202 lands, which is hopefully any day now. As such I'm going to make this assertion non-fatal for the time being over in bug 767306, and then re-evaluate after bug 754202 lands.

Comment 7

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.