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"

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

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

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

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?

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

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

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.

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

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

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

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

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

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

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

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

The spike appears only on Mac/Linux.

(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

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.

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.

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

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