Closed Bug 865609 Opened 12 years ago Closed 8 years ago

Oracle JRE crashes often on linux32

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Version:
13 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: lijewski.stefan, Unassigned)

References

Details

(Keywords: crash, regression)

Crash Data

Attachments

(3 files)

crash dump
318.77 KB, application/octet-stream
Details
crash details
639 bytes, text/plain
Details
debug log from java crash
13.41 KB, text/plain
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 Build ID: 2013032900 Steps to reproduce: Install any of Firefox ESR 17 branch on linux i586 (didn't test on 64bit), install any of oracla java 1.7 plugin, then enter oracle java test page: http://www.java.com/en/download/testjava.jsp or other site which use java (many bank sites seems to be). Actual results: Firefox crashes. It seems like every second attempt to open the site leads to crash. Using mozregression tool I get the following url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a79132ac2f05&tochange=812ea773f166 The problem does not exist with openjdk/icedtea, which cannot be used on bank sites. May be related Expected results: The site should open pop-up informing users if they trust the certificated and display java version.
(In reply to lijewski.stefan from comment #0) > https://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=a79132ac2f05&tochange=812ea773f166 I suspect bug 775965 in that range which has many regressions but almost all fixed in version 17.0. Please provide the crash ID from about:crashes. Does it happen in Safe Mode (see https://support.mozilla.org/kb/troubleshoot-firefox-issues-using-safe-mode)? Does it happen with a new profile (see https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles)? Does it happen with Firefox 20? If no, can you find the working range?
Severity: normal → critical
Component: Untriaged → Plug-ins
Flags: needinfo?(lijewski.stefan)
Keywords: crash, regression, stackwanted
Product: Firefox → Core
(In reply to Scoobidiver from comment #1) > Does it happen in Safe Mode Yes, it does. > Does it happen with a new profile Yes, it does. > Does it happen with Firefox 20? If no, can you find the working range? Yes, it does. ID of all crashes: normalwork b3e4dfb3-514a-43c9-a998-3ccb22130425 safemode 586a949c-13da-4bd3-b73b-27b632130425 newprofile 9aee3f9e-dc43-4c3b-a372-9aa3c2130425 firefox20.0 0d1a1adc-1597-4622-9d2b-5e2af2130425 Using mozregression I get following dates: Last good nightly: 2012-08-17 First bad nightly: 2012-08-18
Flags: needinfo?(lijewski.stefan)
Linked crash reports: bp-b3e4dfb3-514a-43c9-a998-3ccb22130425 bp-586a949c-13da-4bd3-b73b-27b632130425 bp-9aee3f9e-dc43-4c3b-a372-9aa3c2130425 bp-0d1a1adc-1597-4622-9d2b-5e2af2130425 There's no Firefox component in the stack trace so I am surprised it's a Firefox regression. It's also a low volume: https://crash-stats.mozilla.com/report/list?signature=libnpjp2.so%400x1c3bf Does it happen with Nightly (see http://nightly.mozilla.org/)?
Crash Signature: [@ libnpjp2.so@0x1c3bf] [@ libnpjp2.so@0x1c3c4]
Flags: needinfo?(lijewski.stefan)
Keywords: stackwanted
Those crashes are on a Java thread. Note in the other threads how we don't resolve symbols in all except the Fx20 crashes - don't we have symbols for ESR17.0.5 on crash-stats? The crash in 20 has the main thread in: [...] libnpjp2.so@0x10c48 nsNPAPIPluginInstance::Stop dom/plugins/base/nsNPAPIPluginInstance.cpp:319 nsPluginHost::StopPluginInstance dom/plugins/base/nsPluginHost.cpp:3183 nsObjectLoadingContent::DoStopPlugin content/base/src/nsObjectLoadingContent.cpp:2509 nsObjectLoadingContent::StopPluginInstance content/base/src/nsObjectLoadingContent.cpp:2553 nsObjectLoadingContent::UnloadObject content/base/src/nsObjectLoadingContent.cpp:2139 InDocCheckEvent::Run [...]
(In reply to Scoobidiver from comment #3) > Linked crash reports: > bp-b3e4dfb3-514a-43c9-a998-3ccb22130425 > bp-586a949c-13da-4bd3-b73b-27b632130425 > bp-9aee3f9e-dc43-4c3b-a372-9aa3c2130425 > bp-0d1a1adc-1597-4622-9d2b-5e2af2130425 > > There's no Firefox component in the stack trace so I am surprised it's a > Firefox regression. > It's also a low volume: > https://crash-stats.mozilla.com/report/list?signature=libnpjp2.so%400x1c3bf > > Does it happen with Nightly (see http://nightly.mozilla.org/)? No it doesn't happen with nightly (23.0a1). Instead the site doesn't run java script. In console I get following lines: ###!!! [Parent][RPCChannel] Error: Channel error: cannot send/recv So it looks like dom.ipc.plugins for java was enabled (which is my workaround for this bug in firefox esr 17).
Flags: needinfo?(lijewski.stefan)
(In reply to lijewski.stefan from comment #5) > No it doesn't happen with nightly (23.0a1). Instead the site doesn't run > java script. In console I get following lines: > ###!!! [Parent][RPCChannel] Error: Channel error: cannot send/recv > > So it looks like dom.ipc.plugins for java was enabled (which is my > workaround for this bug in firefox esr 17). Right, we finally run Java out-of-process again for Linux/OSX from Firefox 21 on (bug 823559). So the Java plugin crashes not taking down your browser is expected. If Java crashed you still get crash reports for it though, could you put an id/link for Nightly here as well?
Attached file crash dump —
I don't get crash report, but there are some in 'Crash Report/pending', which seems to be related with libnpjp2. I attached them as well.
Attached file crash details —
You should see them in about:crashes and be able to force submitting them by clicking the links. Anyway, i just checked and i can't reproduce this on Ubuntu 12.04 64bit on both Fx ESR-17.0.5 and 20 with the latest Java 7. Is there anything specific to your setup? Are you always allowing Java explicitly or using "allow always" for the click-to-play block?
(In reply to Georg Fritzsche [:gfritzsche] from comment #4) > Those crashes are on a Java thread. > Note in the other threads how we don't resolve symbols in all except the > Fx20 crashes - don't we have symbols for ESR17.0.5 on crash-stats? KaiRo, any idea on this?
Flags: needinfo?(kairo)
(In reply to Georg Fritzsche [:gfritzsche] from comment #9) (In reply to Georg Fritzsche [:gfritzsche] from comment #9) > You should see them in about:crashes and be able to force submitting them by > clicking the links. I don't have anything in about:crashes. > > Anyway, i just checked and i can't reproduce this on Ubuntu 12.04 64bit on > both Fx ESR-17.0.5 and 20 with the latest Java 7. I've tested it only on 32bit arch (openSuSE 11.2 and 11.4). Currently I'm reproducing it on vmware virtual machine, but our users are using physical machines (also 32bit). > Is there anything specific to your setup? Are you always allowing Java > explicitly or using "allow always" for the click-to-play block? Normally I must forcing to allow always Java, it's crucially for our users. But the same happens with fresh, clean profile from Firefox installation
(In reply to lijewski.stefan from comment #2) > Using mozregression I get following dates: > Last good nightly: 2012-08-17 > First bad nightly: 2012-08-18 This corresponds to: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a79132ac2f05&tochange=812ea773f166 Which has several plugin changes. Biggest suspects: Bug 782703, Bug 767639, maybe Bug 751809
Status: UNCONFIRMED → NEW
Ever confirmed: true
Weird, i can't reproduce either with OpenSUSE 11.4 32bit VM installation, Java SE 7u21, Fx ESR17.0.5 & Fx 20. Next-best option i see is pushing some builds to try for download to narrow it down.
(In reply to Georg Fritzsche [:gfritzsche] from comment #10) > (In reply to Georg Fritzsche [:gfritzsche] from comment #4) > > Those crashes are on a Java thread. > > Note in the other threads how we don't resolve symbols in all except the > > Fx20 crashes - don't we have symbols for ESR17.0.5 on crash-stats? > > KaiRo, any idea on this? If it's our official release binaries, we should have symbols. If it's some builds created by someone else, we could easily just not have those symbols. openSUSE should push them to us, but I don't know if they actually, do, their package packager :wolfiR should know.
Flags: needinfo?(kairo)
Right, i was assuming that this was an official release and not a SUSE or custom build. Stefan, can you confirm?
(In reply to Georg Fritzsche [:gfritzsche] from comment #16) > And that's the first set of builds for narrowing down the offending patch: > None of them was good I afraid. Crash ID are as follows: > r882ce0d4a294 - > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/georg. > fritzsche@googlemail.com-df53ac38e7e6/try-linux/firefox-17.0a1.en-US.linux- > i686.tar.bz2 ID: bp-78dd958d-01e6-4361-88b6-750432130426 > r471f34ddcceb - > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/georg. > fritzsche@googlemail.com-efb5e531ada9/try-linux/firefox-17.0a1.en-US.linux- > i686.tar.bz2 ID: bp-65d8ddf2-851c-46aa-8442-101e72130426 > r66e1e2f6f108 - > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/georg. > fritzsche@googlemail.com-feb2da46974e/try-linux/firefox-17.0a1.en-US.linux- > i686.tar.bz2 ID: bp-16ab287b-a1d9-4d55-b5de-90d022130426 > rb15957ea2fba - > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/georg. > fritzsche@googlemail.com-cad2b454f1f3/try-linux/firefox-17.0a1.en-US.linux- > i686.tar.bz2 ID: bp-82af667b-b399-4a2c-8be9-f28542130426
Flags: needinfo?(lijewski.stefan)
(In reply to Georg Fritzsche [:gfritzsche] from comment #15) > Right, i was assuming that this was an official release and not a SUSE or > custom build. Stefan, can you confirm? It really weird - I just installed ubuntu-10.4 i586 on vmware, download firefox-17.0.5 from mozilla and after second attempt I get crash on java site. The crash ID is as follow: bp-80e40204-9ad5-4ddc-8e5a-976672130426 About custom build for openSUSE - yes, firstly I used packages from openSUSE repo. But to test the crash I get firefox binaries from mozilla ftp. I don't remeber from which firefox were the crash ID I provided. The following crash ID is from firefox-17.0.5-ESR binary downloaded from mozilla ftp: bp-3846f3a2-38a4-4d1d-b1ef-b90d62130426
(In reply to lijewski.stefan from comment #18) > It really weird - I just installed ubuntu-10.4 i586 on vmware, download > firefox-17.0.5 from mozilla and after second attempt I get crash on java > site. > The crash ID is as follow: > bp-80e40204-9ad5-4ddc-8e5a-976672130426 > The following crash ID is from firefox-17.0.5-ESR binary downloaded from > mozilla ftp: > bp-3846f3a2-38a4-4d1d-b1ef-b90d62130426 Hm, what Java installation are you using? Using dump_sym from google-breakpad i get the following debug identifier for jre1.7.0_21/lib/i386/libnpjp2.so: 8BEEE944E6921A0FBFD6FD365978B60B0 This doesn't match the debug identifier for libnpjp2.so in your last crash reports: 709E99702D51D6405781F4A72098A8D80
Flags: needinfo?(lijewski.stefan)
(In reply to lijewski.stefan from comment #18) > bp-80e40204-9ad5-4ddc-8e5a-976672130426 [...] > bp-3846f3a2-38a4-4d1d-b1ef-b90d62130426 OK, looking into the other thread, our Mozilla symbols are OK in those. SO the comment #4 / comment #10 question of having symbols for our ESR builds is solved. This of course doesn't help the Java crash, but I somewhat feel like it's a probably in Java itself, actually.
(In reply to Georg Fritzsche [:gfritzsche] from comment #19) > (In reply to lijewski.stefan from comment #18) > > It really weird - I just installed ubuntu-10.4 i586 on vmware, download > > firefox-17.0.5 from mozilla and after second attempt I get crash on java > > site. > > The crash ID is as follow: > > bp-80e40204-9ad5-4ddc-8e5a-976672130426 > > > The following crash ID is from firefox-17.0.5-ESR binary downloaded from > > mozilla ftp: > > bp-3846f3a2-38a4-4d1d-b1ef-b90d62130426 > > Hm, what Java installation are you using? > Using dump_sym from google-breakpad i get the following debug identifier for > jre1.7.0_21/lib/i386/libnpjp2.so: > 8BEEE944E6921A0FBFD6FD365978B60B0 > > This doesn't match the debug identifier for libnpjp2.so in your last crash > reports: > 709E99702D51D6405781F4A72098A8D80 Java from oracle site (tar.gz, i586): https://www.java.com/en/download/linux_manual.jsp?locale=en Normally I used symlinks via /etc/alternatives, which points to: javaplugin -> /usr/java/jre1.7.0_21/lib/i386/libnpjp2.so
Flags: needinfo?(lijewski.stefan)
(In reply to Georg Fritzsche [:gfritzsche] from comment #20) > > That's a surprise. Anyway, next set: > Again, all crashes. The only difference was it took more tries to get the crashes - I mean not after every second attempt firefox crashes. IDs: > r5c8e8efc80a8 - > bp-7bae3a8d-a161-40af-9245-7e3e92130427 > r7bd865cc52c5 - > bp-81df2bf1-423b-4e09-bf23-7d3612130427 > r28944cefdd3c - > bp-419987fd-1a81-49c2-8320-31a2d2130427 I just encounter probably a clue why it's not so easy to reproduce the bug. If I start firefox without any profile the crash doesn't occurs. I mean, the following line: rm -R ~/.mozilla;./firefox http://www.java.com/en/download/testjava.jsp make firefox works every time. I don't know what should I check now - which file in .mozilla can be responsible for crashes? Wiping ~/.java doesn't help.
(In reply to lijewski.stefan from comment #23) > I just encounter probably a clue why it's not so easy to reproduce the bug. > If I start firefox without any profile the crash doesn't occurs. I mean, the > following line: > > rm -R ~/.mozilla;./firefox http://www.java.com/en/download/testjava.jsp pluginreg.dat and (unlikely) extensions.sqlite could be tried separately. If it's a specific file, maybe we can reproduce with it when uploaded. If the crashes are occuring less often, maybe the regression range you initially posted is not completely right.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #21) > OK, looking into the other thread, our Mozilla symbols are OK in those. SO > the comment #4 / comment #10 question of having symbols for our ESR builds > is solved. Right, maybe they weren't official releases after all. Thanks for checking.
(In reply to Georg Fritzsche [:gfritzsche] from comment #24) > (In reply to lijewski.stefan from comment #23) > > I just encounter probably a clue why it's not so easy to reproduce the bug. > > If I start firefox without any profile the crash doesn't occurs. I mean, the > > following line: > > > > rm -R ~/.mozilla;./firefox http://www.java.com/en/download/testjava.jsp > > pluginreg.dat and (unlikely) extensions.sqlite could be tried separately. If > it's a specific file, maybe we can reproduce with it when uploaded. > The problem is in the Cache directory. Wiping it out before starting firefox make java plugin works every time. > If the crashes are occuring less often, maybe the regression range you > initially posted is not completely right. Should I replay mozregression? Right now, when I know I have to delete profile with every nigthly downloaded and try it at least 5 times, the regression should be better.
(In reply to lijewski.stefan from comment #26) > Should I replay mozregression? Right now, when I know I have to delete > profile with every nigthly downloaded and try it at least 5 times, the > regression should be better. Yes please, lets see if we can pinpoint the right trigger this time.
This one should be good this time. It's far from the first set, but I hope properly tested: Last good nightly: 2012-02-08 First bad nightly: 2012-02-09 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4b9608fd670c&tochange=7c0ba1c98ff7
Version: 17 Branch → 13 Branch
Candidates i see: * Fix Bug 657588. http://hg.mozilla.org/mozilla-central/rev/b584b4be0a00 * Bug 723379: Be more strict about not instantiating plugin instances before they have an object frame. Also fix a bug causing object frame creation to fail. http://hg.mozilla.org/mozilla-central/rev/4e6f683d3006 * Bug 723473: Fix crash with Flashblock, regression from bug 90268. http://hg.mozilla.org/mozilla-central/rev/7c0ba1c98ff7
(In reply to Georg Fritzsche [:gfritzsche] from comment #30) > ... and another set of builds to test: ..and again all crashes... > rev 06b063c001b6 - bp-c32df585-88af-4439-adec-4808f2130430 > rev b584b4be0a00 - bp-b72aa811-fd4f-4212-801f-9a63e2130430 > rev 7c0ba1c98ff7 - bp-822ccaa5-1975-49cd-bbf9-744562130430
Hardware: x86_64 → x86
(In reply to Georg Fritzsche [:gfritzsche] from comment #32) > Alright; if we are testing in the right range, this should contain > non-crashing revisions: Only the second one (rev 5e7fd9d0a3e9) was almost crash resistant - it takes about 5-7 restarts to get crash. > > * rev d2d46b209502 bp-bf36489b-128b-4b8e-abc0-66a562130504 > * rev 5e7fd9d0a3e9 bp-fe358956-5247-4e96-9300-965282130504 > * rev 4e6f683d3006 bp-97c2c2cf-8f76-41da-9ddb-e19952130504 > * rev 3e7875d6ee51 bp-500885d6-d5e6-4cef-9d0b-cdec42130504 > * rev 4a2364cb6489 bp-a714a628-d82a-4f4c-94cb-1e4632130504
(In reply to lijewski.stefan from comment #33) > (In reply to Georg Fritzsche [:gfritzsche] from comment #32) > > Alright; if we are testing in the right range, this should contain > > non-crashing revisions: > > Only the second one (rev 5e7fd9d0a3e9) was almost crash resistant - it takes > about 5-7 restarts to get crash. Hm, the first build in there is from the oldest revision of the regression range you found (d2d46b209502). Are you sure that you can't crash with a Nightly before that?
(In reply to Georg Fritzsche [:gfritzsche] from comment #34) > Hm, the first build in there is from the oldest revision of the regression > range you found (d2d46b209502). Are you sure that you can't crash with a > Nightly before that? Sorry for long delay - searching for crashes seems to be more and more treacherous when going back with versions. Using following test procedure with mozregresion: -clear (rm -R) ~/.mozilla -populate ~/.mozilla with empty profile containing only symlink to libnpjp2.so symlink; -download nightly; -test every version at least 15 times finally I get crash range: Last good nightly: 2012-01-31 First bad nightly: 2012-02-01 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-01-31&enddate=2012-02-01
(In reply to lijewski.stefan from comment #35) > Pushlog: > http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-01- > 31&enddate=2012-02-01 It's exactly: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3f26b7bee352&tochange=e18c7bc2c28e I think it's a regression from bug 90268.
Right, that looks like bug 90268, in which case this doesn't really help as that was a major change to the plugin code. Stefan, if you could confirm (builds should be available soon): * rev b506d48ef7aa (last before bug 90268) http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/georg.fritzsche@googlemail.com-9864eec20b1f/ * rev 15b00ab7f22d (bug 90268 landing) http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/georg.fritzsche@googlemail.com-eb0ca4c1638b/
(In reply to Georg Fritzsche [:gfritzsche] from comment #37) > > * rev b506d48ef7aa (last before bug 90268) Seems to be stable (more then 15 attempts without crash) > * rev 15b00ab7f22d (bug 90268 landing) Crashes after several attempts. b6e0e11c-43d9-46d8-9ac6-e2de22130513
Blocks: 90268
Thanks for confirming Stefan. Unfortunately this being bug 90268 that means we don't really have more information now. johns, do you have an idea on what else we could try to narrow this down?
Flags: needinfo?(jschoenick)
So if I'm reading this right: post bug 90268, oracle JRE (not openJDK) crashes on 32-bit linux only, in the Java thread. This is almost certainly a Java bug, but we might be able to work around it. Stefan - Can you give this a shot in the 2013-04-10 nightly? For a period we would synchronously stop the plugin when the document went inactive, but then that was changed back in the nightly prior to your test in comment 5. We also changed this behavior slightly in ESR-17.0.6 to resolve a different bug, so if you could verify that it still crashes there we can rule out that bug as the issue. A slightly more involved debugging step would be to grab this build I just pushed, with more logging statements around all the CheckPluginStopEvent scheduling (which was InDocCheckEvent in ESR17). https://tbpl.mozilla.org/?tree=Try&rev=01e925c89710 If you could run this build with verbose plugin debugging, trigger the crash, and upload the resulting output: > NSPR_LOG_MODULES=objlc:5,Plugin:5,PluginNPP:5,PluginNPN:5 ./firefox | tee javacrash.log That would be helpful for identifying the exact sequence of events the Oracle JRE is having issues with.
Flags: needinfo?(jschoenick) → needinfo?(lijewski.stefan)
Summary: oracle java crahes firefox esr 17 → Oracle JRE crashes often on linux32
(In reply to John Schoenick [:johns] from comment #40) > > Stefan - Can you give this a shot in the 2013-04-10 nightly? For a period we > would synchronously stop the plugin when the document went inactive, but > then that was changed back in the nightly prior to your test in comment 5. > We also changed this behavior slightly in ESR-17.0.6 to resolve a different > bug, so if you could verify that it still crashes there we can rule out that > bug as the issue. ERS-17.0.6 crashes. Nightly 23.0a1 from 2013-04-10 also crashes (after changing dom.ipc.plugins to false): bp-8abd4b1c-cb0b-4315-a7bd-fc41a2130521 > > A slightly more involved debugging step would be to grab this build I just > pushed, with more logging statements around all the CheckPluginStopEvent > scheduling (which was InDocCheckEvent in ESR17). > > https://tbpl.mozilla.org/?tree=Try&rev=01e925c89710 > Should I build this from source? I'm not familiar with Mercurial...
Flags: needinfo?(lijewski.stefan)
(In reply to John Schoenick [:johns] from comment #40) > https://tbpl.mozilla.org/?tree=Try&rev=01e925c89710 > > If you could run this build with verbose plugin debugging, trigger the > crash, and upload the resulting output: > > NSPR_LOG_MODULES=objlc:5,Plugin:5,PluginNPP:5,PluginNPN:5 ./firefox | tee javacrash.log > > That would be helpful for identifying the exact sequence of events the > Oracle JRE is having issues with. There isn't much output: 1369135384734 Marionette INFO MarionetteComponent loaded 1369135384747 Marionette INFO marionette not enabled ++DOCSHELL 0x86df3b0 == 1 [id = 1] ++DOMWINDOW == 1 (0x86de154) [serial = 1] [outer = (nil)] ++DOMWINDOW == 2 (0x86ea854) [serial = 2] [outer = 0x86de154] ++DOCSHELL 0x8ac2320 == 2 [id = 2] ++DOMWINDOW == 3 (0x8ac5d74) [serial = 3] [outer = (nil)] ++DOMWINDOW == 4 (0x8ac7c2c) [serial = 4] [outer = 0x8ac5d74] ++DOMWINDOW == 5 (0x8b11484) [serial = 5] [outer = 0x86de154] ++DOCSHELL 0x8e54770 == 3 [id = 3] ++DOMWINDOW == 6 (0x8e553bc) [serial = 6] [outer = (nil)] ++DOCSHELL 0x8e56c98 == 4 [id = 4] ++DOMWINDOW == 7 (0x8e5734c) [serial = 7] [outer = (nil)] ++DOCSHELL 0x92c6bc8 == 5 [id = 5] ++DOMWINDOW == 8 (0x92877ec) [serial = 8] [outer = (nil)] ++DOMWINDOW == 9 (0x93cfe6c) [serial = 9] [outer = 0x92877ec] ++DOMWINDOW == 10 (0x9281ca4) [serial = 10] [outer = 0x8e553bc] ++DOMWINDOW == 11 (0x91b459c) [serial = 11] [outer = 0x8e5734c] ++DOMWINDOW == 12 (0x9110ad4) [serial = 12] [outer = 0x92877ec] ++DOMWINDOW == 13 (0x9905a3c) [serial = 13] [outer = 0x92877ec] For application/x-java-vm found plugin libnpjp2.so LoadPlugin() /usr/java/jre1.7.0_21/lib/i386/libnpjp2.so returned 9334118 nsPluginNativeWindowGtk2: NPPVpluginNeedsXEmbed=1 nsPluginNativeWindowGtk2: call SetWindow with xid=0x380023c nsPluginNativeWindowGtk2: call SetWindow with xid=0x380023c JVMLauncher.afterStart(): starting JVM process watcher
(In reply to lijewski.stefan from comment #43) > There isn't much output: Ack, sorry, the output we need would be going to stderr, so: > NSPR_LOG_MODULES=objlc:5,Plugin:5,PluginNPP:5,PluginNPN:5 ./firefox 2>&1 | tee javacrash.log
(In reply to lijewski.stefan from comment #45) > Created attachment 752600 [details] > debug log from java crash Is this from http://www.java.com/en/download/testjava.jsp ? The log appears to be creating a plugin, calling navigator.plugins.refresh(), immediately removing it from the document, and then creating a second plugin. Before the second plugin begins to start, the first plugin is stopped, and java prints |JVMLauncher.afterStart(): starting JVM process watcher| inside the Stop() call. Can you give this one more shot on this page: http://people.mozilla.com/~jschoenick/plugin/java.htm Which just starts a single applet. See if that page crashes when loading it slowly, then maybe try refreshing rapidly. If Java only crashes when it is stopped too quickly, we may be able to hack around that.
(In reply to John Schoenick [:johns] from comment #46) > (In reply to lijewski.stefan from comment #45) > > Created attachment 752600 [details] > > debug log from java crash > > Is this from http://www.java.com/en/download/testjava.jsp ? It's from polish version of this site, but it's irrelevant - I also get the crash on english site. > > The log appears to be creating a plugin, calling > navigator.plugins.refresh(), immediately removing it from the document, and > then creating a second plugin. Before the second plugin begins to start, the > first plugin is stopped, and java prints |JVMLauncher.afterStart(): starting > JVM process watcher| inside the Stop() call. > > Can you give this one more shot on this page: > http://people.mozilla.com/~jschoenick/plugin/java.htm > > Which just starts a single applet. See if that page crashes when loading it > slowly, then maybe try refreshing rapidly. If Java only crashes when it is > stopped too quickly, we may be able to hack around that. I was unable to crash at this page in any way.
I'm marking this bug as WONTFIX per bug #1269807. For more information see - https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: