e10s crash in xpc::AddonWindowOrNull(JSObject*)

VERIFIED FIXED in mozilla35

Status

()

defect
--
critical
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: snorp, Assigned: bholley)

Tracking

({crash})

unspecified
mozilla35
All
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s?, firefox35-)

Details

(crash signature)

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.
tracking-e10s: --- → ?
Summary: crash in xpc::AddonWindowOrNull(JSObject*) → e10s crash in xpc::AddonWindowOrNull(JSObject*)
Product: Firefox → Core

Comment 1

5 years ago
[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

5 years ago
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
If this is e10s-only, then we don't need to track it for 35 since it will only manifest on Nightly.
Blocks: 1065452
Flags: needinfo?(bobbyholley)
Assignee

Comment 4

5 years ago
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.
Flags: needinfo?(bobbyholley)
Assignee

Updated

5 years ago
Duplicate of this bug: 1068164
Assignee

Updated

5 years ago
Blocks: 1068225
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.
Flags: needinfo?(bobbyholley)
Assignee

Comment 8

5 years ago
(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).
Flags: needinfo?(bobbyholley) → needinfo?(ryanvm)
(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.
https://hg.mozilla.org/mozilla-central/rev/55b46de164d8
Assignee: nobody → bobbyholley
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(ryanvm)
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
Depends on: 1071675
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
Status: RESOLVED → VERIFIED
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?
Assignee

Comment 14

5 years ago
(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!
You need to log in before you can comment on or make changes to this bug.