Crash @ nsPluginHost::TrySetUpPluginInstance

RESOLVED DUPLICATE of bug 723473

Status

()

Core
Plug-ins
--
critical
RESOLVED DUPLICATE of bug 723473
8 years ago
5 years ago

People

(Reporter: Tomcat, Unassigned)

Tracking

({crash, topcrash})

Trunk
mozilla13
crash, topcrash
Points:
---
Bug Flags:
blocking1.9.2 -

Firefox Tracking Flags

(firefox13+ fixed)

Details

(Whiteboard: [crashkill], crash signature)

Attachments

(1 obsolete attachment)

(Reporter)

Description

8 years ago
filing from the Topcrash stats: 

http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.5.3&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsPluginHostImpl%3A%3ATrySetUpPluginInstance%28char%20const*%2C%20nsIURI*%2C%20nsIPluginInstanceOwner*%29

might be related to acrobat reader, comments mention opening a pdf in a webpage and crashreports mention nppdf32.dll 8.1.0.137

also some comments mention clicked "emusic download link"
Flags: blocking1.9.2?
(Reporter)

Updated

8 years ago
Whiteboard: [crashkill]
(Reporter)

Comment 1

8 years ago
chofmann, bc can  have a url list for this, to test with acrobat reader ?

Comment 2

8 years ago
I'll teach you to fish. See me on irc. ;-)
(Reporter)

Comment 3

8 years ago
(In reply to comment #2)
> I'll teach you to fish. See me on irc. ;-)

yep bob did this :) and as soon as i have results i will update the bug!

Updated

8 years ago
OS: Mac OS X → Windows XP
(Reporter)

Comment 4

8 years ago
not reproducible so far :(
Not blocking based on comment 4 and the fact that nobody seems to be working on it. Have we figured out how common this continues to be?
Flags: blocking1.9.2? → blocking1.9.2-

Comment 6

8 years ago
This is a bug in our code. I can see it without reproducing.
Assignee: nobody → joshmoz
By opening up a couple of minidumps it seems like the stack I get there is this:

nsPluginHostImpl::TrySetUpPluginInstance(const char * aMimeType=0x042db868, nsIURI * aURL=0x0264b450, nsIPluginInstanceOwner * aOwner=0x04092900)  Line 3863 + 0x6
nsPluginHostImpl::SetUpPluginInstance(const char * aMimeType=0x1006441b, nsIURI * aURL=0x00862124, nsIPluginInstanceOwner * aOwner=0x008f2cf0)  Line 3674	C++
SearchTable(PLDHashTable * table=0x021ba3a4, const void * key=0x042db868, unsigned int keyHash=40154192, PLDHashOperator op=67709184)  Line 456 + 0x14
nsPluginHostImpl::InstantiateFullPagePlugin(const char * aMimeType=0x00000047, nsIURI * aURI=0x00010005, nsIStreamListener * & aStreamListener=, nsIPluginInstanceOwner * aOwner=0x0012facc)  Line 3484 + 0xb
nsCOMPtr<nsISupports>::~nsCOMPtr<nsISupports>()  + 0x2f4cb4

Comment 8

8 years ago
Created attachment 413733 [details] [diff] [review]
non-fix v1.0

This looked like missing null checks to me, in which case this patch would fix the problem, but jst says the pointer in the crashes is not null so this won't work.

Updated

8 years ago
Assignee: joshmoz → nobody

Comment 9

8 years ago
this seems fluctuating between 300-500 crashes per day over the last 6 weeks.

it doesn't look like its observed in 3.6 so *not* blocking on it makes sense.  maybe it should probably get wanted next, or wanted 1.9.1, or what ever the wanted 3.5.x flag thingy is.

distribution of all versions where the nsPluginHostImpl::TrySetUpPluginInstance crash was found on 20091119-crashdata.csv
 279 Firefox 3.5.5
 131 Firefox 3.0.15
  12 Firefox 3.5.3
   8 Firefox 3.5.4
[long tail back to 3.0 removed...]

Updated

8 years ago
Summary: Crash [@nsPluginHostImpl::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*) ] → Crash [@ nsPluginHostImpl::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*) ]
This appears in 3.6 as well, but slightly different signature due to a class name change.
Summary: Crash [@ nsPluginHostImpl::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*) ] → Crash [@ nsPluginHostImpl::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*) ][@ nsPluginHost::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*) ]

Comment 11

6 years ago
It is #22 top crasher in 4.0.
Some comments talk about opening a pdf.

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsPluginHost%3A%3ATrySetUpPluginInstance%28char%20const*%2C%20nsIURI*%2C%20nsIPluginInstanceOwner*%29&version=Firefox%3A4.0

Comment 12

6 years ago
It is #24 top crasher in 5.0b2 over the last 3 days. Maybe related to bug 561264.
(Assignee)

Updated

6 years ago
Crash Signature: [@ nsPluginHostImpl::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*) ] [@ nsPluginHost::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*) ]
Duplicate of this bug: 685594

Updated

6 years ago
Assignee: nobody → joshmoz
Crash Signature: [@ nsPluginHostImpl::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*) ] [@ nsPluginHost::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*) ] → [@ nsPluginHostImpl::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*) ] [@ nsPluginHost::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*) ]

Updated

6 years ago
Attachment #413733 - Attachment is obsolete: true

Comment 14

6 years ago
I looked over stacks and code for a bit this morning, my latest theory...

1179 nsresult nsPluginHost::SetUpPluginInstance(const char *aMimeType,
1180                                            nsIURI *aURL,
1181                                            nsIPluginInstanceOwner *aOwner)
1182 {
1183   NS_ENSURE_ARG_POINTER(aOwner);
1184 
1185   nsresult rv = NS_OK;
1186 
1187   rv = TrySetUpPluginInstance(aMimeType, aURL, aOwner);
1188 
1189   // if we fail, refresh plugin list just in case the plugin has been
1190   // just added and try to instantiate plugin instance again, see bug 143178
1191   if (NS_FAILED(rv)) {
1192     // we should also make sure not to do this more than once per page
1193     // so if there are a few embed tags with unknown plugins,
1194     // we don't get unnecessary overhead
1195     // let's cache document to decide whether this is the same page or not
1196     nsCOMPtr<nsIDocument> document;
1197     aOwner->GetDocument(getter_AddRefs(document));

If the call to TrySetUpPluginInstance at line 1187 does anything that might destroy the object frame for the instance and then returns a failure code the

Comment 15

6 years ago
I accidentally submitted comment 14 before I was done with it...

Comment 16

6 years ago
I looked over stacks and code for a bit this morning, my latest theory...

1179 nsresult nsPluginHost::SetUpPluginInstance(const char *aMimeType,
1180                                            nsIURI *aURL,
1181                                            nsIPluginInstanceOwner *aOwner)
1182 {
1183   NS_ENSURE_ARG_POINTER(aOwner);
1184 
1185   nsresult rv = NS_OK;
1186 
1187   rv = TrySetUpPluginInstance(aMimeType, aURL, aOwner);
1188 
1189   // if we fail, refresh plugin list just in case the plugin has been
1190   // just added and try to instantiate plugin instance again, see bug 143178
1191   if (NS_FAILED(rv)) {
1192     // we should also make sure not to do this more than once per page
1193     // so if there are a few embed tags with unknown plugins,
1194     // we don't get unnecessary overhead
1195     // let's cache document to decide whether this is the same page or not
1196     nsCOMPtr<nsIDocument> document;
1197     aOwner->GetDocument(getter_AddRefs(document));

If the call to TrySetUpPluginInstance at line 1187 does anything that might destroy the object frame for the instance (calls into the plugin which runs script, for example) and then returns a failure code, then the call to aOwner->GetDocument on line 1197 will cause a crash because destruction of the object frame will have freed "aOwner".

Updated

6 years ago
Assignee: joshmoz → nobody

Comment 17

6 years ago
There's a spike in crashes from 13.0a1/20120201 and it's now #2 top crasher in this build.
The regression window for the spike is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3f26b7bee352&tochange=e18c7bc2c28e
It's likely caused by bug 90268.

One comment says: "Trying to read mail in zimbra"

The first frames of the stack look like:
Frame 	Module 	Signature 	Source
0 	libxul.so 	nsPluginHost::TrySetUpPluginInstance 	dom/plugins/base/nsPluginHost.cpp:1356
1 	libxul.so 	nsPluginHost::SetUpPluginInstance 	dom/plugins/base/nsPluginHost.cpp:1225
2 	libxul.so 	nsPluginHost::InstantiateEmbeddedPlugin 	dom/plugins/base/nsPluginHost.cpp:1084
3 	libxul.so 	nsObjectLoadingContent::InstantiatePluginInstance 	content/base/src/nsObjectLoadingContent.cpp:637
4 	libxul.so 	nsObjectLoadingContent::SyncStartPluginInstance 	content/base/src/nsObjectLoadingContent.cpp:1958
5 	libxul.so 	nsHTMLPluginObjElementSH::GetPluginInstanceIfSafe 	dom/base/nsDOMClassInfo.cpp:9590
6 	libxul.so 	nsHTMLPluginObjElementSH::SetupProtoChain 	dom/base/nsDOMClassInfo.cpp:9657
7 	libxul.so 	nsHTMLPluginObjElementSH::PostCreate 	dom/base/nsDOMClassInfo.cpp:9757
8 	libxul.so 	FinishCreate 	js/xpconnect/src/XPCWrappedNative.cpp:645
9 	libxul.so 	XPCWrappedNative::GetNewOrUsed 	js/xpconnect/src/XPCWrappedNative.cpp:583
10 	libxul.so 	XPCConvert::NativeInterface2JSObject 	js/xpconnect/src/XPCConvert.cpp:1056
11 	libxul.so 	xpc_qsXPCOMObjectToJsval 	js/xpconnect/src/XPCQuickStubs.cpp:1088
12 	libxul.so 	nsIDOMDocument_GetElementById 	obj-firefox/js/xpconnect/src/dom_quickstubs.cpp:3192
13 	libxul.so 	js::InvokeKernel 	js/src/jscntxtinlines.h:311
14 	libxul.so 	js::Interpret 	js/src/jsinterp.cpp:2801

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsPluginHost%3A%3ATrySetUpPluginInstance
https://crash-stats.mozilla.com/report/list?signature=nsPluginHost%3A%3ATrySetUpPluginInstance%28char%20const*%2C%20nsIURI*%2C%20nsIPluginInstanceOwner*%29
Blocks: 90268
Crash Signature: [@ nsPluginHostImpl::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*) ] [@ nsPluginHost::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*) ] → [@ nsPluginHostImpl::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*)] [@ nsPluginHost::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*)] [@ nsPluginHost::TrySetUpPluginInstance]
tracking-firefox13: --- → ?
Keywords: topcrash
OS: Windows XP → All
Hardware: x86 → All
Summary: Crash [@ nsPluginHostImpl::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*) ][@ nsPluginHost::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*) ] → Crash @ nsPluginHost::TrySetUpPluginInstance
Version: 1.9.1 Branch → Trunk

Comment 18

6 years ago
The spike appears only on Mac/Linux.

Comment 19

6 years ago
(In reply to Jim Mathies [:jimm] from comment #18)
> The spike appears only on Mac/Linux.
And 64-bit Windows:
https://crash-stats.mozilla.com/report/list?signature=nsPluginHost%3A%3ATrySetUpPluginInstance%28char%20const*%2C%20nsIURI*%2C%20nsIPluginInstanceOwner*%29

Comment 20

6 years ago
I checked manually crash reports (Windows, Mac, Linux) and they have the Flashblock extension, except bp-000fd9ba-f54f-4a26-b47d-90e992120202.
It might be related to bug 723473 and bug 723476.

Updated

6 years ago
Crash Signature: [@ nsPluginHostImpl::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*)] [@ nsPluginHost::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*)] [@ nsPluginHost::TrySetUpPluginInstance] → nsIPluginInstanceOwner*)] [@ nsPluginHost::TrySetUpPluginInstance] [@ nsCOMPtr_base::assign_from_qi | nsPluginStreamListenerPeer::OnStartRequest] [@ nsPluginHostImpl::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*)] [@ nsPl&hellip;
I hit this just now:
https://crash-stats.mozilla.com/report/index/bp-1f73885b-e279-4623-9fd3-784752120205

I have Flashblock installed, and I had Facebook and Twitter open. (I also hit bug 723473 earlier today, so it's possible these are two potential crashes from the same situation.)
Yeah, this is brutal for me right now on Mac - holler if there's anything I can do to help with analysis/reproduction.

Updated

6 years ago
tracking-firefox13: ? → +
> Yeah, this is brutal for me right now on Mac - holler if there's
> anything I can do to help with analysis/reproduction.

Precise	STR would be helpful, if you have them :-)

Also a list of your extensions, and if disabling one of them makes the
problem go away.
When it was live, I could only protect myself by disabling all plugins, and afaict, STR were "load plugin content." :)

Of course, it hasn't happened in the last day, perhaps unhelpfully.
Whoever sees these crashes, please keep looking for reproducible STR.  But I've already got 100% reproducible STR for bug 723520, which I suspect is related (both seem to be crashes on access to a deleted nsIURI object).
I just hit this crash. I had just restored my session from another crash. I clicked on a tab with Gmail, which started loading. I then clicked on the next tab, and Firefox immediately crashed. (I have Flashblock installed.)
Crash Signature: nsIPluginInstanceOwner*)] [@ nsPluginHost::TrySetUpPluginInstance] [@ nsCOMPtr_base::assign_from_qi | nsPluginStreamListenerPeer::OnStartRequest] [@ nsPluginHostImpl::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*)] [@ nsPl&hellip; → nsIPluginInstanceOwner*)] [@ nsPluginHost::TrySetUpPluginInstance] [@ @0x0 | nsPluginHostImpl::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*) ] [@ nsCOMPtr_base::assign_from_qi | nsPluginStreamListenerPeer::OnStartRequest&hellip;

Updated

5 years ago
Crash Signature: nsIPluginInstanceOwner*)] [@ nsPluginHost::TrySetUpPluginInstance] [@ @0x0 | nsPluginHostImpl::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*) ] [@ nsCOMPtr_base::assign_from_qi | nsPluginStreamListenerPeer::OnStartRequest&hellip; → nsIPluginInstanceOwner*) ] [@ nsCOMPtr_base::assign_from_qi | nsPluginStreamListenerPeer::OnStartRequest] nsIPluginInstanceOwner*)] [@ nsPluginHost::TrySetUpPluginInstance] [@ @0x0 | nsPluginHost::TrySetUpPluginInstance] [@ @0x0 | nsPluginHost&hellip;

Comment 27

5 years ago
There have been no crashes in 13.0a1/20120209 and above for the six crash signatures.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 723473

Updated

5 years ago
status-firefox13: --- → fixed

Updated

5 years ago
Target Milestone: --- → mozilla13
You need to log in before you can comment on or make changes to this bug.