It is a new crash signature that first appeared in 4.0b12pre/20110209. With combined signatures, it is #5 top crasher in 4.0b12pre over the last week. Signature npjpi160_23.dll@0x1657 UUID d2f0b6c5-b173-4a37-9497-d4c812110210 Time 2011-02-10 08:17:18.849820 Uptime 426 Last Crash 281954 seconds (3.3 days) before submission Install Age 433 seconds (7.2 minutes) since version was first installed. Product Firefox Version 4.0b12pre Build ID 20110210030400 Branch 2.0 OS Windows NT OS Version 6.0.6002 Service Pack 2 CPU x86 CPU Info GenuineIntel family 6 model 15 stepping 11 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x0 App Notes AdapterVendorID: 10de, AdapterDeviceID: 0407, AdapterDriverVersion: 7.15.11.138 Frame Module Signature [Expand] Source 0 npjpi160_23.dll npjpi160_23.dll@0x1657 1 npjpi160_23.dll npjpi160_23.dll@0x16d7 2 xul.dll nsNPAPIPlugin::CreatePlugin modules/plugin/base/src/nsNPAPIPlugin.cpp:518 3 xul.dll CreateNPAPIPlugin modules/plugin/base/src/nsPluginHost.cpp:1789 4 xul.dll nsPluginHost::EnsurePlugin modules/plugin/base/src/nsPluginHost.cpp:1956 5 xul.dll nsPluginHost::ClearSiteData modules/plugin/base/src/nsPluginHost.cpp:1974 6 xul.dll NS_InvokeByIndex_P xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102 7 xul.dll XPC_WN_CallMethod js/src/xpconnect/src/xpcwrappednativejsops.cpp:1593 8 mozjs.dll js::Interpret js/src/jsinterp.cpp:4758 9 mozjs.dll js::RunScript js/src/jsinterp.cpp:640 10 mozjs.dll js::Invoke js/src/jsinterp.cpp:720 11 mozjs.dll js::ExternalInvoke js/src/jsinterp.cpp:841 12 mozjs.dll JS_CallFunctionValue js/src/jsapi.cpp:5048 13 xul.dll nsXPCWrappedJSClass::CallMethod js/src/xpconnect/src/xpcwrappedjsclass.cpp:1701 14 xul.dll nsXPCWrappedJS::CallMethod js/src/xpconnect/src/xpcwrappedjs.cpp:588 15 kernel32.dll CompareStringWorker 16 xul.dll SharedStub xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141 17 xul.dll nsCOMPtr_base::assign_with_AddRef obj-firefox/xpcom/build/nsCOMPtr.cpp:88 18 xul.dll nsCycleCollectingAutoRefCnt::decr obj-firefox/dist/include/nsISupportsImpl.h:211 19 xul.dll nsXULDocument::Release content/html/document/src/nsHTMLDocument.cpp:310 20 xul.dll nsRefPtr<mozilla::dom::Element>::~nsRefPtr<mozilla::dom::Element> obj-firefox/dist/include/nsAutoPtr.h:969 21 xul.dll nsEventTargetChainItem::HandleEventTargetChain content/events/src/nsEventDispatcher.cpp:398 22 xul.dll nsEventStateManager::GetEventTarget content/events/src/nsEventStateManager.cpp:4144 23 kernel32.dll CompareStringWorker 24 xul.dll nsEventTargetChainItem::HandleEventTargetChain content/events/src/nsEventDispatcher.cpp:341 25 @0x11fe311f 26 xul.dll DocumentViewerImpl::LoadComplete layout/base/nsDocumentViewer.cpp:1051 27 xul.dll nsDocShell::EndPageLoad docshell/base/nsDocShell.cpp:6080 28 xul.dll nsCOMPtr_base::assign_from_qi obj-firefox/xpcom/build/nsCOMPtr.cpp:96 29 xul.dll nsDocShell::OnStateChange docshell/base/nsDocShell.cpp:5934 The regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3470891975c7&tochange=fd0817e454fe More reports at: https://crash-stats.mozilla.com/query/query?product=Firefox&range_value=1&range_unit=weeks&query_search=signature&query_type=startswith&query=npjpi&build_id=&process_type=any&hang_type=any&do_query=1

scoobidiver, the most likely candidate here is bug 626602, which was backed out in the following nightly. Can you see whether this crash was a one-night stand?

It is still there in 4.0b12pre/20110211: bp-a28554cd-dabd-41f9-b7cc-51d332110211

Crap, this is a regression from Flash LSO clearing. Beltzner, should we just bounce those out at this point?

Specifically, some part of bug 508167, bug 625497, or bug 625496.

I can look into this today.

So far I haven't been able to reproduce this on Windows 7 with today's nightly build and the latest version of Java (SE6U23).

It has also been in 4.0b11 since 2/9/2011! So it is an external cause. The likely cause could be an MS Hotfix from the patch tuesday.

Yeah, this doesn't look to be a regression from the NPAPI Clear Private Data landing. It's happening in many version of Firefox including 3.6.13. Marking blocking minus as it isn't specific to Firefox 4.

Looks like we're trying to load the old XPCOM Java plugin. The only Java plugin from Oracle supported on Windows in Firefox 3.6 or higher is JavaPlugin2, which has a dll named "npjp2.dll".

Can you please tell us the exact steps to reproduce the crash ? I cannot make it happen so far. What's the action to trigger the crash ?

We really don't know, this bug appears because of statistical data in crash-stats.mozilla.com.

Unlike 4.0b11 or b12pre (started on 9/2/11), they are residual crash signatures in 3.6.13. It is #1 top crasher over the last 3 days in 4.0b12pre (may be also related to a regression?). It is beyond #300 top crasher over the last 3 days in 4.0b11. It is beyond #300 top crasher over the last 3 days in 3.6.13. A lot of comments say they were checking the Java version at java.com. I can not reproduce in 3.6.13, 4.0b11 and 4.0b12pre.

The same start date in 4.0b11 and 4.0b12pre is only a coincidence because 4.0b11 has been released around this date. The crasher rank difference let me think it is finally a regression and the regression range is the one in comment 0. So comment 5 is right. Cumulated Java 1.6 crash reports give: 4.0b12pre/20110211: 25 4.0b12pre/20110210: 93 4.0b12pre/20110209: 136 It drops down, so may be once someone crashed, the cache is cleared and it no longer crashes after. I renominate it for 2.0.

I believe this is probably a case where we have a disabled plugin-tag for the old Java plugin. In bug 633427 we found that we are instantiating even disabled plugins in order to clear private data, and I bet that's where things are going bad.

This is a shot in the dark. I don't know that this will fix the problem and I haven't even tried to compile this patch. Just saving this theory.

I think this needs to block beta12, it's a huge crash problem for the people who see it and I don't want to alienate the beta userbase.

This patch plus blocklisting the plugin should make sure it doesn't load.

Comment on attachment 512834 [details] [diff] [review] fix v1.1 Is it acceptable for GetFile to return a localFile that points to a directory that doesn't exist? (Looks like it's always been that way.) The Exists/IsDirectory checks made sure we returned a valid dir for the '\\new_plugin' case, but not for the '\\bin' case.

(In reply to comment #19) > Is it acceptable for GetFile to return a localFile that points to a directory > that doesn't exist? (Looks like it's always been that way.) The > Exists/IsDirectory checks made sure we returned a valid dir for the > '\\new_plugin' case, but not for the '\\bin' case. I think its fine to not check, none of the other code does that and the only caller checks for existence and appears to fail gracefully if it isn't a dir.

pushed to mozilla-central http://hg.mozilla.org/mozilla-central/rev/7f8e4c2ca53f between this and the block in bug 634639 we should be good to go