[e10s] Null deref in nsFrameLoader::DoSendAsyncMessage

VERIFIED FIXED in Firefox 40

Status

()

Core
DOM: Content Processes
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: billm, Assigned: billm)

Tracking

({crash})

Trunk
mozilla40
x86_64
Linux
crash
Points:
---

Firefox Tracking Flags

(e10sm7+, firefox40 verified)

Details

(crash signature)

Attachments

(1 attachment)

Comment 1

3 years ago
If it makes any difference to your triage, this is one of the top crash signatures on nightly and it's often a startup crash.
Keywords: crash
tracking-e10s: --- → m7+
Assignee: nobody → wmccloskey

Comment 2

3 years ago
Startup crash is from having add-on.

Clean nightly profile. Extracted from http://www.firefox.com.cn/ cehomepage-0.10.28.xpi crash after install, restart;
bp-c2ea7baf-74a3-4bf1-98ec-3d21a2150425

It isn't the only add-on causing the crash but only one I have tracked down;
e.g. crash reported also from one of;
https://crash-stats.mozilla.com/report/index/d34141d5-1850-4a2f-a7bc-a09ef2150420#extensions
Created attachment 8598340 [details] [diff] [review]
patch

I think the problem is that we're sending a CPOW before the CPOW manager (really the JavaScriptParent object) has been created. To avoid races, the child process is always the one that creates the JavaScriptChild/Parent. But if an add-on in the parent sends a CPOW before the child has done any CPOW stuff, then we'll crash right now. This patch turns it into an exception.

I also added code to try to create the CPOW manager as soon as possible in the child. It might not be soon enough, but it's the best we can do without major architectural changes.
Attachment #8598340 - Flags: review?(dvander)
Attachment #8598340 - Flags: review?(dvander) → review+
https://hg.mozilla.org/mozilla-central/rev/e3cb99d0589f
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox40: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Duplicate of this bug: 1106610
Socorro shows:
- original signature [1] - no crashes over the past 28 days
- new <T> signature [2] - no crashes over the past 28 days in Firefox 40 builds after April 27

[1] - https://crash-stats.mozilla.com/report/list?range_unit=days&range_value=28&signature=nsFrameLoader%3A%3ADoSendAsyncMessage%28JSContext%2A%2C+nsAString_internal+const%26%2C+mozilla%3A%3Adom%3A%3AStructuredCloneData+const%26%2C+JS%3A%3AHandle%3CJSObject%2A%3E%2C+nsIPrincipal%2A%29#tab-sigsummary
[2] - https://crash-stats.mozilla.com/report/list?range_unit=days&range_value=28&signature=nsFrameLoader%3A%3ADoSendAsyncMessage%28JSContext%2A%2C+nsAString_internal+const%26%2C+mozilla%3A%3Adom%3A%3AStructuredCloneData+const%26%2C+JS%3A%3AHandle%3CT%3E%2C+nsIPrincipal%2A%29#tab-reports
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsFrameLoader::DoSendAsyncMessage(JSContext*, nsAString_internal const&, mozilla::dom::StructuredCloneData const&, JS::Handle<JSObject*>, nsIPrincipal*) ] → [@ nsFrameLoader::DoSendAsyncMessage(JSContext*, nsAString_internal const&, mozilla::dom::StructuredCloneData const&, JS::Handle<JSObject*>, nsIPrincipal*) ] [@ nsFrameLoader::DoSendAsyncMessage(JSContext*, nsAString_internal const&, mozilla::dom:&hellip;
status-firefox40: fixed → verified
You need to log in before you can comment on or make changes to this bug.