Closed Bug 1109793 Opened 9 years ago Closed 7 years ago

Reproducible crash with e10s: sync XHR on unonload of MS support articles happens during CPOW message

Categories

(Core :: DOM: Content Processes, defect, P4)

x86
Windows 7
defect

Tracking

()

RESOLVED FIXED
Tracking Status
e10s + ---

People

(Reporter: benjamin, Assigned: billm)

Details

(Keywords: crash, reproducible)

STR:
* have e10s on
* load http://support.microsoft.com/kb/3006625 in a browser tab
* close that tab

ENVIRONMENT:
I have the following addons enabled:
DOM Inspector
Tree-style tabs
Mass password reset
Tree Style Tab

ACTUAL:
On page unload, the content process crashes like this:
https://crash-stats.mozilla.com/report/index/a9ea679f-aa61-41d9-986a-ef3a42141210

This is caused by running the canunload event handler from within a CPOW, which in this case causes a sync XHR which spins the event loop and intentionally crashes since spinning an event loop from within a CPOW handler is verboten.

I think we should have crashed earlier at either of the following locations:
http://hg.mozilla.org/mozilla-central/annotate/5b01216f97f8/dom/events/EventDispatcher.cpp#l698 DispatchDOMEvent
Or somewhere in the chain of EventListener::HandleEvent -> CallSetup::CallSetup -> JS::Call

I don't know whether this is related to one of the addons or not... I'll try to test that later.
Bill, remind me why we couldn't crash earlier on event dispatch, instead of waiting for the content sync XHR to spin the event loop?
Flags: needinfo?(wmccloskey)
Too many add-ons want to dispatch an event in the content process. We were getting tons of crash reports from that. In every case I looked at, the add-on was making a new event and calling dispatchEvent using some content DOM node as the target.
Flags: needinfo?(wmccloskey)
Assignee: nobody → gkrizsanits
I installed DOM Inspector, Mass Password reset and Tree Style Tab from AMO. I couldn't find "Tree-style tabs" (is this a typo?). With these addosn and current nightly I couldn't reproduce this crash. Benjamin, can you please re-test?
Flags: needinfo?(benjamin)
This crash is definitely still possible. I think maybe I should take this bug.
Assignee: gkrizsanits → wmccloskey
Flags: needinfo?(benjamin)
Severity: normal → critical
back to my question in comment 3, Benjamin can you still reproduce this? After talking to Bill, this is theoretically possible, but that doesn't rise to the level of tracking it for milestone 6.
Flags: needinfo?(benjamin)
No, the STR in comment 1 don't reproduce this currently.
Flags: needinfo?(benjamin)
I haven't managed to reproduce this issue on the latest Aurora(46.0a2). I installed all specified add-ons, and after I closed the provided link, Firefox didn't crash. Also, Socorro does not show any more crashes with the same signature on the last 28 days.

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160205004003
Priority: -- → P4
This was fixed by CPOW cancellation I think.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.