1068163 - e10s crash in xpc::AddonWindowOrNull(JSObject*)

Status: VERIFIED FIXED

(Core :: General, defect)

Description

[James Willcox (:snorp) ([e-mail]) (he/him)]

This bug was filed from the Socorro interface and is 
report bp-c5ef1fca-fde0-44c8-95ef-680052140916.
=============================================================

https://crash-stats.mozilla.com/report/index/c5ef1fca-fde0-44c8-95ef-680052140916

I enabled e10s and got a crash immediately on startup. Looks to be addon related. I have a bunch of them, so hard to say which one. If I had to guess, maybe omnibar or proflist.

Comment 1

[Robert Kaiser]

[Tracking Requested - why for this release]:
Looking at the reports tab in https://crash-stats.mozilla.com/report/list?product=Firefox&signature=xpc%3A%3AAddonWindowOrNull%28JSObject%2A%29 it looks like this specific signature is only happening with today's build (so far), but it's a really common and bad startup crash.

Comment 2

[Robert Kaiser]

On Windows, this is an EXCEPTION_BREAKPOINT at 0x571317b4 in 32bit or 0x7ffdcbd3ec9c in 64bit, on Mac this is an EXC_BAD_ACCESS / KERN_INVALID_ADDRESS at 0x0 and on Linux a SIGSEGV at 0x0

Comment 3

[:Gavin Sharp [email: [e-mail]]]

If this is e10s-only, then we don't need to track it for 35 since it will only manifest on Nightly.

Comment 4

[Bobby Holley (:bholley)]

So, this assert is making sure that addons don't mess with their global's prototype in a way that breaks our compartment-per-addon system (setting the addon global to the "main" global). Clearly, this world is a cruel one.

We should definitely turn off this assertion for now, but we also need to investigate which addons are doing this, figure out what they're doing, and determine whether we need to whitelist that behavior or just get them to stop.

I'll use this bug to turn off the release-mode assertion.

Comment 6

[Bobby Holley (:bholley)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3488fc0bf6ef

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think the crash numbers on this are bad enough that you should coordinate with sheriffs/releng on:
 (a) landing this directly on m-c, and
 (b) triggering a new nightly.

Comment 8

[Bobby Holley (:bholley)]

(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from comment #7)
> I think the crash numbers on this are bad enough that you should coordinate
> with sheriffs/releng on:
>  (a) landing this directly on m-c, and
>  (b) triggering a new nightly.

I'm guessing Ryan is the guy to do both (a) and (b).

Comment 9

[Trevor Rowbotham [:rowbot]]

(In reply to Bobby Holley (:bholley) from comment #4)
> So, this assert is making sure that addons don't mess with their global's
> prototype in a way that breaks our compartment-per-addon system (setting the
> addon global to the "main" global). Clearly, this world is a cruel one.
> 
> We should definitely turn off this assertion for now, but we also need to
> investigate which addons are doing this, figure out what they're doing, and
> determine whether we need to whitelist that behavior or just get them to
> stop.
> 
> I'll use this bug to turn off the release-mode assertion.

The Disconnect[1] addon was causing me to run into this today, however, I am not testing e10s currently, so I don't think this is e10s only.  Here are some of my crash reports.

https://crash-stats.mozilla.com/report/index/e3ebe818-41ac-43f3-9d6e-598592140916
https://crash-stats.mozilla.com/report/index/723bdea2-c64c-4427-a39b-7afc22140916
https://crash-stats.mozilla.com/report/index/eab07dd1-0c33-4763-a941-366752140916

[1] https://addons.mozilla.org/en-US/firefox/addon/disconnect/

Hope this helps.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/55b46de164d8

Comment 11

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/3488fc0bf6ef

Comment 12

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Socorro data [1] for the last 4 weeks shows a low number of crashes:
- 37.0a1 - 1 crash
- 36.0a1 - 15 crashes
- 35.0a2 - 46 crashes
- 35.0b1 - 3 crashes

I'm not quite sure why we have instances of this crash on 35 Aurora and Beta (since it's an e10s crash), but the numbers are low, so I think we can call this one fixed.

[1] - https://crash-stats.mozilla.com/report/list?product=Firefox&range_unit=days&range_value=28&signature=xpc%3A%3AAddonWindowOrNull%28JSObject%2A%29#tab-sigsummary

Comment 13

[Johannes Pfrang [:johnp]]

Just experienced this crash in a non-e10s session:

bp-9423b3a8-f1f6-4e6e-9c5a-7e8a22141223

fwiw I also use the disconnect add-on like in comment #9, but the crash happens at "if (!IsInAddonScope(aObj))" a couple lines before the assert. Seperate bug?

Comment 14

[Bobby Holley (:bholley)]

(In reply to Johannes Pfrang [:johnp] from comment #13)
> Just experienced this crash in a non-e10s session:
> 
> bp-9423b3a8-f1f6-4e6e-9c5a-7e8a22141223
> 
> fwiw I also use the disconnect add-on like in comment #9, but the crash
> happens at "if (!IsInAddonScope(aObj))" a couple lines before the assert.
> Seperate bug?

Yeah, that looks like a separate bug. If you can reproduce it, please file with STR!