Closed Bug 828889 Opened 7 years ago Closed 6 years ago

crash in npjp2.dll@0xc997 with Java SE 7 Update 10 to 17

Categories

(Plugins Graveyard :: Java (Oracle), defect, P3, critical)

Product:
Plugins Graveyard
Component:
Java (Oracle)
Platform:
x86
Windows 7
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: scoobidiver, Unassigned)

Details

(Keywords: crash)

Crash Data

It's likely the new form of bug 803965 with Java SE 7 Update 10.
It's currently #61 top browser crasher in 17.0.1 and #24 in 18.0.

Here are correlations per module version:
    100% (70/70) vs.   1% (842/60471) npjp2.dll
        100% (70/70) vs.   0% (229/60471) 10.10.2.18

Signature 	npjp2.dll@0xc997 More Reports Search
UUID	047a6851-4567-4b3c-8217-0ea222130110
Date Processed	2013-01-10 09:47:05
Uptime	35
Install Age	35 seconds since version was first installed.
Install Time	2013-01-10 09:44:44
Product	Firefox
Version	18.0
Build ID	20130104151925
Release Channel	release
OS	Windows NT
OS Version	5.2.3790 Service Pack 2
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 15 stepping 11
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x1
App Notes 	
Cisco VPN
AdapterVendorID: 0x1002, AdapterDeviceID: 0x515e, AdapterSubsysID: 03051014, AdapterDriverVersion: 8.24.3.0
D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers- 
EMCheckCompatibility	True
Adapter Vendor ID	0x1002
Adapter Device ID	0x515e
Total Virtual Memory	2147352576
Available Virtual Memory	1765081088
System Memory Use Percentage	59
Available Page File	2086789120
Available Physical Memory	438099968

Frame 	Module 	Signature 	Source
0 	npjp2.dll 	npjp2.dll@0xc997 	
1 	npjp2.dll 	npjp2.dll@0xcb24 	
2 	npjp2.dll 	npjp2.dll@0xc250 	
3 	msvcr100.dll 	_threadstartex 	f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c:292
4 	kernel32.dll 	BaseThreadStart 	

More reports at:
https://crash-stats.mozilla.com/report/list?signature=npjp2.dll%400xc997
It's also correlated to Java SE7 U13:
          7% (15/214) vs.   0% (328/174704) 7.0.110.21
          1% (2/214) vs.   0% (14/174704) 7.0.110.22
         92% (197/214) vs.   0% (584/174704) 7.0.130.20
Summary: crash in npjp2.dll@0xc997 with Java SE 7 Update 10 → crash in npjp2.dll@0xc997 with Java SE 7 Update 10 & 13
It's #22 top browser crasher in 18.0.2 with an upward tendency (Java SE 7 U13 is not blocked).
Depends on: 823559
Keywords: topcrash
I don't think this can be related to bug 823559, which should have been non-Windows only and this crash is on Windows.
No longer depends on: 823559
And in case it's not clear, this is a *browser* crash because Java is not run in a plugin process on Windows, so it's taking down all of Firefox.

I don't really know who our current technical contacts are at Oracle Java.
Bsmedberg,

I can connect you with Milton Smith who is the security contact I've worked with at Oracle for Java items.
CCing Calvin who worked on the Oracle side for bug 750480.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #4)
> And in case it's not clear, this is a *browser* crash because Java is not
> run in a plugin process on Windows, so it's taking down all of Firefox.
If I added bug 823559 as a dependent bug and not a blocker one, it's because the OOP for Java will morph this signature from 20.0. In any case, I said it's a regression.
(In reply to Georg Fritzsche [:gfritzsche] from comment #6)
> CCing Calvin who worked on the Oracle side for bug 750480.

I'm working in a different team now.
Including Thomas in the cc list.
(In reply to Calvin Cheung from comment #8)
> I'm working in a different team now.
> Including Thomas in the cc list.

Ah, thanks Calvin.

(In reply to Scoobidiver from comment #7)
> If I added bug 823559 as a dependent bug and not a blocker one, it's because
> the OOP for Java will morph this signature from 20.0. In any case, I said
> it's a regression.

Bug 823559 doesn't affect Windows, Java will stay in-process there.
What's the exact steps to reproduce the crash ?   Any specific URL to load to cause the crash ?
Keywords: needURLs
Keywords: needURLs
(In reply to Thomas Ng from comment #10)
> What's the exact steps to reproduce the crash ?   Any specific URL to load
> to cause the crash ?

We don't have exact steps at this point. One of the URLs in comment 11 might trigger it, but the URLs are not necessarily the crashing site.

Do the crash-offset offer any insight and possibly allow symbolification? The signature for those crashes seems to be persistent per Java plugin version.
https://crash-stats.mozilla.com/report/list?signature=npjp2.dll%400xc997
It's also applicable to Java SE7 U15:
    100% (379/379) vs.   1% (1763/187421) java.dll
          2% (7/379) vs.   0% (112/187421) 7.0.110.21
         72% (274/379) vs.   0% (871/187421) 7.0.130.20
         26% (98/379) vs.   0% (382/187421) 7.0.150.3
Summary: crash in npjp2.dll@0xc997 with Java SE 7 Update 10 & 13 → crash in npjp2.dll@0xc997 with Java SE 7 Update 10, 13 & 15
Priority: -- → P3
Thanks for the information - we have a bug filed with Java Plug-in and is looking into it.
Probably because of bug 843373, it's only #38 top browser crasher in 19.0 so no longer a top crasher.
Keywords: topcrash
Here are recent correlations:
   100% (190/190) vs.   1% (1144/139851) java.dll
          1% (1/190) vs.   0% (24/139851) 7.0.100.18
          2% (3/190) vs.   0% (42/139851) 7.0.110.21
          3% (6/190) vs.   0% (94/139851) 7.0.130.20
          4% (7/190) vs.   0% (241/139851) 7.0.150.3
         91% (173/190) vs.   0% (540/139851) 7.0.170.2
Summary: crash in npjp2.dll@0xc997 with Java SE 7 Update 10, 13 & 15 → crash in npjp2.dll@0xc997 with Java SE 7 Update 10 to 17
Java SE7 U17 is not CTP blocklisted, so it's now #20 top browser crasher in 19.0.2.
Keywords: topcrash
Should we extend the Java blocks again, Alex?
Flags: needinfo?(akeybl)
We have developed a fix for this based on the crash stack info here so far.   The fix will be included in 7u21.  Is there a way to test if our fix really solved the actual crash ?   I suppose there is no easy way ?
(In reply to Thomas Ng from comment #19)
> Is there a way to test if our fix really solved the actual crash ? I suppose there is
> no easy way ?
If you have a sufficient Beta population, we can see whether Java SE7 U21 is still affected or not but it doesn't seem so as I don't see Java SE7 U18 and above.
It's #40 browser crasher in 20.0.1 and #79 in 21.0b3 now that Java 7 SE21 is released.

It has likely morphed into bug 863740, not yet a top crasher.
Keywords: topcrash
Just quickly sampled a set of recent crashes and all those users seem to still be on U17.
Is it working better in 7u21 ?  or still crashing the same way ?
(In reply to Thomas Ng from comment #23)
> Is it working better in 7u21 ?
It seems it no longer happens in SE 7 U21, not because it's fixed but because the crashing address shifted into bug 863740.
We will close it as soon as we get correlation files (the latest ones date from April 9) to confirm.
(In reply to Scoobidiver from comment #24)
> We will close it as soon as we get correlation files (the latest ones date
> from April 9) to confirm.
Here there are:
    100% (183/183) vs.   2% (2489/136061) java.dll
          1% (1/183) vs.   0% (15/136061) 7.0.100.18
          2% (4/183) vs.   0% (39/136061) 7.0.110.21
          1% (1/183) vs.   0% (28/136061) 7.0.130.20
          1% (1/183) vs.   0% (42/136061) 7.0.150.3
         96% (175/183) vs.   0% (570/136061) 7.0.170.2
          1% (1/183) vs.   1% (1583/136061) 7.0.210.11
Let's consider it's fixed in SE 7 U21 with only one crash.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Flags: needinfo?(akeybl)
Product: Plugins → Plugins Graveyard
You need to log in before you can comment on or make changes to this bug.