Closed Bug 828889 Opened 8 years ago Closed 8 years ago
crash in npjp2
.dll@0xc997 with Java SE 7 Update 10 to 17
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: 22.214.171.124 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) 126.96.36.199 1% (2/214) vs. 0% (14/174704) 188.8.131.52 92% (197/214) vs. 0% (584/174704) 184.108.40.206
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).
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 ?
Top URLs: 181 http://www.targetingnow.com/delivery 57 about:blank 50 http://cmt.caixa.gov.br/ 36 https://www.santandernet.com.br/default.asp 34 http://fwbox.fastwebnet.it/webmail/comp/X.sms?Login 29 https://www.telepass.it/AutostradeETIWeb/j_security_check 26 https://countermail.com/webmail.php 24 http://www.wsistudents.com/eav2home.jhtml 21 http://www.facebook.com/ 20 https://w3.ibm.com/tools/expenses/ersInstaller.shtml 18 about:newtab 16 https://unctim.unc.edu/wfc/applications/suitenav/navigation.do 15 http://px.pluginhandler.info/x 13 https://www.facebook.com/ 12 https://www.kronos.cornell.edu/wfc/applications/suitenav/navigation.do 10 https://www.mojebanka.cz/InternetBanking/ (there are more with fewer hits, and I left out a few adult websites)
(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) 220.127.116.11 72% (274/379) vs. 0% (871/187421) 18.104.22.168 26% (98/379) vs. 0% (382/187421) 22.214.171.124
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
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.
Here are recent correlations: 100% (190/190) vs. 1% (1144/139851) java.dll 1% (1/190) vs. 0% (24/139851) 126.96.36.199 2% (3/190) vs. 0% (42/139851) 188.8.131.52 3% (6/190) vs. 0% (94/139851) 184.108.40.206 4% (7/190) vs. 0% (241/139851) 220.127.116.11 91% (173/190) vs. 0% (540/139851) 18.104.22.168
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.
Should we extend the Java blocks again, Alex?
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.
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) 22.214.171.124 2% (4/183) vs. 0% (39/136061) 126.96.36.199 1% (1/183) vs. 0% (28/136061) 188.8.131.52 1% (1/183) vs. 0% (42/136061) 184.108.40.206 96% (175/183) vs. 0% (570/136061) 220.127.116.11 1% (1/183) vs. 1% (1583/136061) 18.104.22.168 Let's consider it's fixed in SE 7 U21 with only one crash.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Product: Plugins → Plugins Graveyard
You need to log in before you can comment on or make changes to this bug.