Closed
Bug 723523
Opened 13 years ago
Closed 13 years ago
Crash [@ nsPluginInstanceOwner::CreateWidget ] [@ nsCOMPtr_base::assign_assuming_AddRef | nsObjectFrame::PrepForDrawing ]
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(firefox10 unaffected, firefox11 unaffected, firefox12 unaffected, firefox13+ verified, firefox-esr10 unaffected)
RESOLVED
FIXED
mozilla13
Tracking | Status | |
---|---|---|
firefox10 | --- | unaffected |
firefox11 | --- | unaffected |
firefox12 | --- | unaffected |
firefox13 | + | verified |
firefox-esr10 | --- | unaffected |
People
(Reporter: scoobidiver, Assigned: jaas)
References
Details
(5 keywords, Whiteboard: [sg:critical][qa+:mihaelav][advisory-tracking+])
Crash Data
Attachments
(1 file)
(deleted),
patch
|
jimm
:
review+
|
Details | Diff | Splinter Review |
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•13 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•13 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•13 years ago
|
||
Hey Marcia, can we try and reproduce this?
Comment 4•13 years ago
|
||
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•13 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.
Comment 6•13 years ago
|
||
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
Comment 7•13 years ago
|
||
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)
Comment 8•13 years ago
|
||
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.
Comment 9•13 years ago
|
||
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•13 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 | ||
Comment 11•13 years ago
|
||
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)
Summary: Crash in nsPluginInstanceOwner::CreateWidget @ nsCOMPtr_base::assign_assuming_AddRef | nsObjectFrame::PrepForDrawing → Crash [@ nsPluginInstanceOwner::CreateWidget ] [@ nsCOMPtr_base::assign_assuming_AddRef | nsObjectFrame::PrepForDrawing ]
Updated•13 years ago
|
Attachment #603276 -
Flags: review?(jmathies) → review+
Assignee | ||
Comment 13•13 years ago
|
||
try run for fix v1.0
https://tbpl.mozilla.org/?tree=Try&rev=0c4792b1fceb
Assignee | ||
Comment 14•13 years ago
|
||
pushed to mozilla-inbound
http://hg.mozilla.org/integration/mozilla-inbound/rev/c8ff0f77a129
Updated•13 years ago
|
Whiteboard: [sg:critical]
Updated•13 years ago
|
status-firefox10:
--- → unaffected
status-firefox11:
--- → unaffected
status-firefox12:
--- → unaffected
Comment 15•13 years ago
|
||
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
Updated•13 years ago
|
status-firefox-esr10:
--- → unaffected
Comment 16•13 years ago
|
||
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
Comment 17•13 years ago
|
||
There is no testcase to reproduce this crash, right?
Comment 18•12 years ago
|
||
(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+]
Comment 19•12 years ago
|
||
I can't reproduce a crash in Firefox 11, pre-fix, with that testcase.
Updated•12 years ago
|
Group: core-security
Comment 20•12 years ago
|
||
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!
Comment 21•12 years ago
|
||
I think that's good enough Mihaela. Thanks.
Keywords: verified-beta
Whiteboard: [sg:critical][qa+] → [sg:critical][qa+:mihaelav]
Updated•12 years ago
|
Whiteboard: [sg:critical][qa+:mihaelav] → [sg:critical][qa+:mihaelav][advisory-tracking+]
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•