Crash [@ nsPluginInstanceOwner::CreateWidget ] [@ nsCOMPtr_base::assign_assuming_AddRef | nsObjectFrame::PrepForDrawing ]

RESOLVED FIXED in Firefox 13

Status

()

Core
Plug-ins
--
critical
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: Scoobidiver (away), Assigned: Josh Aas)

Tracking

(5 keywords)

13 Branch
mozilla13
x86_64
Windows 7
crash, regression, reproducible, topcrash, verified-beta
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox10 unaffected, firefox11 unaffected, firefox12 unaffected, firefox13+ verified, firefox-esr10 unaffected)

Details

(Whiteboard: [sg:critical][qa+:mihaelav][advisory-tracking+], crash signature)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
It's currently #21 top crasher in the first build of 13.0a1.
The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3f26b7bee352&tochange=e18c7bc2c28e
It's likely caused by bug 90268.

Signature 	nsCOMPtr_base::assign_assuming_AddRef(nsISupports*) | nsObjectFrame::PrepForDrawing(nsIWidget*) More Reports Search
UUID	2d083f0f-8656-49e4-82cb-e78592120202
Date Processed	2012-02-02 11:39:51
Uptime	6723
Install Age	1.9 hours since version was first installed.
Install Time	2012-02-02 09:47:10
Product	Firefox
Version	13.0a1
Build ID	20120201031146
Release Channel	nightly
OS	Windows NT
OS Version	6.0.6002 Service Pack 2
Build Architecture	amd64
Build Architecture Info	family 6 model 30 stepping 5
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0xffffffffffffffff
App Notes 	
AdapterVendorID: 0x10de, AdapterDeviceID: 0x0603, AdapterSubsysID: 1058174b, AdapterDriverVersion: 8.15.11.8637
D3D10 Layers? D3D10 Layers-
D3D9 Layers? D3D9 Layers-
WebGL? WebGL-
EMCheckCompatibility	True

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsCOMPtr_base::assign_assuming_AddRef 	
1 	xul.dll 	nsObjectFrame::PrepForDrawing 	layout/generic/nsObjectFrame.cpp:389
2 	xul.dll 	nsRefPtr<nsPresContext>::~nsRefPtr<nsPresContext> 	obj-firefox/dist/include/nsAutoPtr.h:907
3 	xul.dll 	nsComponentManagerImpl::GetServiceByContractID 	xpcom/components/nsComponentManager.cpp:1410
4 	xul.dll 	nsPluginInstanceOwner::CreateWidget 	dom/plugins/base/nsPluginInstanceOwner.cpp:3317
5 	xul.dll 	nsPluginHost::SetUpPluginInstance 	dom/plugins/base/nsPluginHost.cpp:1225
6 	xul.dll 	ns_if_addref<nsListScrollSmoother*> 	obj-firefox/dist/include/nsISupportsUtils.h:94
7 	xul.dll 	nsACString_internal::Replace 	obj-firefox/dist/include/nsTSubstring.h:378
8 	xul.dll 	nsPluginInstanceOwner::GetInstance 	dom/plugins/base/nsPluginInstanceOwner.cpp:495
9 	xul.dll 	nsPluginHost::InstantiateEmbeddedPlugin 	dom/plugins/base/nsPluginHost.cpp:1096
10 	xul.dll 	SearchTable 	obj-firefox/xpcom/build/pldhash.cpp:472
11 	xul.dll 	nsPrefBranch::RemoveObserver 	modules/libpref/src/nsPrefBranch.cpp:639
12 	xul.dll 	nsComponentManagerImpl::GetService 	xpcom/components/nsComponentManager.cpp:1215
13 	xul.dll 	nsACString_internal::MutatePrep 	xpcom/string/src/nsTSubstring.cpp:162
14 	xul.dll 	nsCOMPtr_base::assign_from_qi 	obj-firefox/xpcom/build/nsCOMPtr.cpp:96
15 	xul.dll 	nsObjectLoadingContent::InstantiatePluginInstance 	content/base/src/nsObjectLoadingContent.cpp:637
16 	xul.dll 	nsPluginStreamListenerPeer::OnStartRequest 	dom/plugins/base/nsPluginStreamListenerPeer.cpp:640
17 	xul.dll 	nsCOMPtr_base::assign_from_gs_contractid 	obj-firefox/xpcom/build/nsCOMPtr.cpp:134
18 	xul.dll 	nsRefPtr<nsPresContext>::~nsRefPtr<nsPresContext> 	obj-firefox/dist/include/nsAutoPtr.h:907
19 	xul.dll 	nsObjectLoadingContent::OnStartRequest 	content/base/src/nsObjectLoadingContent.cpp:902

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsCOMPtr_base%3A%3Aassign_assuming_AddRef%28nsISupports*%29%20|%20nsObjectFrame%3A%3APrepForDrawing%28nsIWidget*%29

Comment 1

6 years ago
This looks like a dead mObjectFrame in nsPluginInstanceOwner. In light of what we discovered in bug 683059, mObjectFrame gets destroyed before the nsPluginInstanceOwner dtor which is where mObjectFrame is nulled out. So in addition to setting the plugin instance in the object frame to null in Destroy, I think we should be nulling out the object frame as well.
(Reporter)

Comment 2

6 years ago
It's now #3 top crasher in 13.0a1.

Th only comment says:
"This version of Nightly seems to have a little heartburn w/ Intellicast's Flash-powered weather map."
Keywords: topcrash

Comment 3

5 years ago
Hey Marcia, can we try and reproduce this?
Keywords: qawanted
While I was checking one of the URLs from this signature I crashed in Bug 724812 Comment 1 - wondering if these two signatures are related.
(Reporter)

Comment 5

5 years ago
(In reply to Marcia Knous [:marcia] from comment #4)
> While I was checking one of the URLs from this signature I crashed in Bug
> 724812 Comment 1 - wondering if these two signatures are related.
This one is specific to 64-bit builds, so it might be the 64-bit version of bug 724812, assuming Breakpad is not good for 64-bit stacks.
I see 185 crashes across the trunk in the last week. 98% of the crashes are on Win 7. One user comment: it keeps shutting down when ever i set my location. That user has no extensions installed.

http://local.msn.com/weather.aspx?q=Bronx-NY&zip=10460
Here are some manual addon correlations:

nsCOMPtr_base::assign_assuming_AddRef(nsISupports*) | nsObjectFrame::PrepForDrawing(nsIWidget*)|EXCEPTION_ACCESS_VIOLATION_READ (21 crashes)
     10% (2/21) vs.   0% (5/1635) TFToolbarX@torrent-finder (Torrent Finder Toolbar, https://addons.mozilla.org/addon/2755)
     10% (2/21) vs.   0% (8/1635) bbrs_002@blabbers.com
     19% (4/21) vs.  12% (189/1635) testpilot@labs.mozilla.com (Mozilla Labs - Test Pilot, https://addons.mozilla.org/addon/13661)
Here are some better STR that I just got using the latest nightly on Win 7:

1. Load http://local.msn.com/ten-day.aspx?q=Middletown-CT&eid=21225&zip=06457
2. Select "Find a location"
3. Keep changing the location to different zip codes
4. Eventually after 3-4 times I generate a crash

The crash usually happens when I start typing the same of the city in the field.
Actually the crash signatures I am getting match Bug 724812.

(In reply to Marcia Knous [:marcia] from comment #8)
> Here are some better STR that I just got using the latest nightly on Win 7:
> 
> 1. Load http://local.msn.com/ten-day.aspx?q=Middletown-CT&eid=21225&zip=06457
> 2. Select "Find a location"
> 3. Keep changing the location to different zip codes
> 4. Eventually after 3-4 times I generate a crash
> 
> The crash usually happens when I start typing the same of the city in the
> field.
Keywords: reproducible

Comment 10

5 years ago
We have STR, it's a top crash - #9 on the trunk. It's not assigned to anybody.
status-firefox13: --- → affected
tracking-firefox13: --- → +
(Assignee)

Updated

5 years ago
Assignee: nobody → joshmoz
(Assignee)

Comment 11

5 years ago
Created attachment 603276 [details] [diff] [review]
fix v1.0

This might do the trick. Clear out the frame pointer as soon as we know the frame will be destroyed.
Attachment #603276 - Flags: review?(jmathies)
(Assignee)

Updated

5 years ago
Summary: Crash in nsPluginInstanceOwner::CreateWidget @ nsCOMPtr_base::assign_assuming_AddRef | nsObjectFrame::PrepForDrawing → Crash [@ nsPluginInstanceOwner::CreateWidget ] [@ nsCOMPtr_base::assign_assuming_AddRef | nsObjectFrame::PrepForDrawing ]
(Assignee)

Updated

5 years ago
Duplicate of this bug: 724812

Updated

5 years ago
Attachment #603276 - Flags: review?(jmathies) → review+
(Assignee)

Comment 13

5 years ago
try run for fix v1.0

https://tbpl.mozilla.org/?tree=Try&rev=0c4792b1fceb
(Assignee)

Updated

5 years ago
Group: core-security
(Assignee)

Comment 14

5 years ago
pushed to mozilla-inbound

http://hg.mozilla.org/integration/mozilla-inbound/rev/c8ff0f77a129

Updated

5 years ago
Whiteboard: [sg:critical]

Updated

5 years ago
status-firefox10: --- → unaffected
status-firefox11: --- → unaffected
status-firefox12: --- → unaffected
https://hg.mozilla.org/mozilla-central/rev/c8ff0f77a129
Status: NEW → RESOLVED
Last Resolved: 5 years ago
status-firefox13: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla13

Updated

5 years ago
status-firefox-esr10: --- → unaffected
Removing qawanted -- the original ask was for a reproducible case which has been found some time ago. We will verify the fix as per our normal schedule -- no need to track any longer with qawanted. Please re-add if there is more we can do.
Keywords: qawanted
There is no testcase to reproduce this crash, right?
(In reply to Al Billings [:abillings] from comment #17)
> There is no testcase to reproduce this crash, right?

My understanding was that comment 9 is the reproducible case. I could be wrong...
Whiteboard: [sg:critical] → [sg:critical][qa+]
I can't reproduce a crash in Firefox 11, pre-fix, with that testcase.
Blocks: 285982
Group: core-security
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0 (beta 4)

Could ot reproduce the crash using steps from comment #8. Also, no crashes with this signature were reported in the last 4 weeks.

Is there anything else that can be done before marking this verified for FF13?

Thanks!
I think that's good enough Mihaela. Thanks.
status-firefox13: fixed → verified
Keywords: verified-beta
Whiteboard: [sg:critical][qa+] → [sg:critical][qa+:mihaelav]
Whiteboard: [sg:critical][qa+:mihaelav] → [sg:critical][qa+:mihaelav][advisory-tracking+]
You need to log in before you can comment on or make changes to this bug.