519752 - Crash @ nsPluginHost::TrySetUpPluginInstance

Status: RESOLVED DUPLICATE of bug 723473

(Core Graveyard :: Plug-ins, defect)

Description

[Carsten Book [:Tomcat]]

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"

Comment 1

[Carsten Book [:Tomcat]]

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

Comment 2

[Bob Clary [:bc] (inactive)]

I'll teach you to fish. See me on irc. ;-)

Comment 3

[Carsten Book [:Tomcat]]

(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!

Comment 4

[Carsten Book [:Tomcat]]

not reproducible so far :(

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

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?

Comment 6

[Josh Aas]

This is a bug in our code. I can see it without reproducing.

Comment 7

[Johnny Stenback (:jst)]

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

[Josh Aas]

Attachment: 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.

Comment 9

[chris hofmann]

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...]

Comment 10

[Johnny Stenback (:jst)]

This appears in 3.6 as well, but slightly different signature due to a class name change.

Comment 11

[Scoobidiver (away)]

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

[Scoobidiver (away)]

It is #24 top crasher in 5.0b2 over the last 3 days. Maybe related to bug 561264.

Comment 14

[Josh Aas]

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

[Josh Aas]

I accidentally submitted comment 14 before I was done with it...

Comment 16

[Josh Aas]

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".

Comment 17

[Scoobidiver (away)]

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

Comment 18

[Jim Mathies [:jimm]]

The spike appears only on Mac/Linux.

Comment 19

[Scoobidiver (away)]

(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

[Scoobidiver (away)]

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.

Comment 21

[(not currently active) Ted Mielczarek]

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.)

Comment 22

[Johnathan Nightingale [:johnath]]

Yeah, this is brutal for me right now on Mac - holler if there's anything I can do to help with analysis/reproduction.

Comment 23

[Steven Michaud [:smichaud] (Retired)]

> 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.

Comment 24

[Johnathan Nightingale [:johnath]]

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.

Comment 25

[Steven Michaud [:smichaud] (Retired)]

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).

Comment 26

[(not currently active) Ted Mielczarek]

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.)

Comment 27

[Scoobidiver (away)]

There have been no crashes in 13.0a1/20120209 and above for the six crash signatures.