Closed Bug 1155241 Opened 6 years ago Closed 6 years ago

crash in nsPluginInstanceOwner::SetFrame(nsPluginFrame*)


(Core :: Plug-ins, defect)

39 Branch
Not set



Tracking Status
firefox37 --- wontfix
firefox38 --- wontfix
firefox39 + fixed
firefox40 --- fixed


(Reporter: aklotz, Assigned: aklotz)


(Keywords: crash)

Crash Data


(1 file)

This bug was filed from the Socorro interface and is 
report bp-3512fd28-e6fc-4b6b-8194-28cc32150415.

nsObjectLoadingContent's pointer to the plugin owner is nullptr by the time the crash notification occurs. This can happen in async init if content stopped the plugin while init was still running asynchronously.
It is now possible for the owner to be nullptr under async plugin init, so we need to add a check for that.
Attachment #8594944 - Flags: review?(bugs)
Attachment #8594944 - Flags: review?(bugs) → review+
Thanks for the quick review!
try push:
Comment on attachment 8594944 [details] [diff] [review]
Add nullptr check

Approval Request Comment
[Feature/regressing bug #]: Async plugin init
[User impact if declined]: Instability. #2 topcrasher on aurora
[Describe test coverage new/current, TreeHerder]: Local, landing on m-c
[Risks and why]: None, trivial patch to eliminate nullptr dereference
[String/UUID change made/needed]: None
Attachment #8594944 - Flags: approval-mozilla-aurora?
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
[Tracking Requested - why for this release]:
This is 10% of all Dev Edition browser crashes right now.
Interestingly, I see this crash signature in 35+. However, the volume is much lower in releases prior to 39. Tracking 39+
Comment on attachment 8594944 [details] [diff] [review]
Add nullptr check

Given that this is a fix for plug-in async init, which can't be tested in Nightly, and that it is a simple fix, I'm approving for Aurora. Aurora+
Attachment #8594944 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.