633463 - Java 1.6 crash clearing private data [@ npjpi160_23.dll@0x1657 ][@ npjpi160_07.dll@0x1674 ][@ npjpi160_06.dll@0x1674 ][@ npjpi160_05.dll@0x1674 ][@ npjpi160_04.dll@0x1674 ][@ npjpi160_03.dll@0x1674 ][@ npjpi160_02.dll@0x1674 ][@ npjpi160_01.dll@0x1674 ]

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Scoobidiver (away)]

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

Comment 2

[Benjamin Smedberg]

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?

Comment 3

[Scoobidiver (away)]

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

Comment 4

[Benjamin Smedberg]

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

Comment 5

[Benjamin Smedberg]

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

Comment 6

[Josh Aas]

I can look into this today.

Comment 7

[Josh Aas]

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

Comment 8

[Scoobidiver (away)]

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.

Comment 9

[Josh Aas]

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.

Comment 10

[Josh Aas]

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

Comment 11

[Thomas Ng]

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 ?

Comment 12

[Benjamin Smedberg]

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

Comment 13

[Scoobidiver (away)]

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.

Comment 14

[Scoobidiver (away)]

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.

Comment 15

[Benjamin Smedberg]

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.

Comment 16

[Josh Aas]

Attachment: fix v1.0

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.

Comment 17

[Benjamin Smedberg]

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.

Comment 18

[Josh Aas]

Attachment: fix v1.1

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

Comment 19

[Jim Mathies [:jimm]]

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.

Comment 22

[Josh Aas]

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

Comment 23

[Josh Aas]

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