User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20020918 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20020918 This simple php script will make mozilla crash every time when java support is enabled. Tried with both Mandrake's latest 1.1 build and the latest nightly build of 1.2 <? header("Content-Type: application/x-java-vm"); passthru("cat /dev/urandom"); ?> Reproducible: Always Steps to Reproduce: 1. Visit the url Mozilla will then instantly crash. If it just offers a file download, maybe you have java disabled. Actual Results: 5 seconds of disk trashing, then mozilla crashes Expected Results: Offered a file download dialog, or at least kept running. This is what it outputs to the console when crashing: jbj@microbob ~/test/mozilla $ ./mozilla INTERNAL ERROR on Browser End:  Initialize. No docbase? System error?:: Resource temporarily unavailable
Oh, and it happens with Java VM 1.3.1_02-b02 and 1.4.1-rc, though I'm not sure if it's java's or Mozilla's fault. Netscape doesn't have the problem though it uses the same java.
wfm using build 2002091804 (trunk) on Win2k + JRE 1.4.1RC.
Confirmed on build 2002092010, Linux 2.4.19 i686, glibc 2.2.5-34, XFree86-4.2.0-3mdk, KDE 3.0.0, JRE 1.4.1fc When debugging the nightly build, it tells me "Program exited with code 0377". When I set a breakpoint at exit(), I get this stack trace: #0 0x405233e2 in exit () from /lib/libc.so.6 #1 0x41142f7c in fopentrace () from /usr/home/matt/.mozilla/plugins/j2re1.4.1/plugin/i386/ns610/libjavaplugin_oji.so #2 0x411344c9 in JavaPluginInstance5::Initialize () from /usr/home/matt/.mozilla/plugins/j2re1.4.1/plugin/i386/ns610/libjavaplugin_oji.so #3 0x41045046 in NSGetModule () from /usr/home/matt/graze/browsers/mz/components/libgkplugin.so
Status: UNCONFIRMED → NEW
Ever confirmed: true
This bug can also be reproduced on Solaris I take it. Reporter: Would you like to provide a testcase for this bug? Thanks!
Assignee: joe.chou → joshua.xia
cc: xiaobin, must jpi exit when GetDocumentBase from Taginfo fail?
Status: NEW → ASSIGNED
I've attached a testcase now
I am sorry that I can't read your testcase. you only attached a binary file. Can you attach source code? for example: html, java or php source? Thanks!
reporter: you means that opening the Random binary garbage file by using mozilla crash the mozilla?
This file is similar to the script I provided inline with the original bugreport, except that it doesn't depend on /dev/urandom joshua: Yes, but the garbage must have the content-type application/x-java-vm. Just clicking the previous (binary) attachment should make your browser crash, at least it does that here. This php script also shows that just one line of text can be used too.
Jonas: You cheat mozilla to identify that there is java application in this page by using php 's header function, but in fact the page is only a Random binary garbage. So JPI fails to get the docbase and exit, and mozilla crash.
Confirm on Linux(RH8.0) mozilla1.2 with JRE1.4.1_01. But I don't think it's a bug anyway... Since if you cheat mozilla, anything will happen. It's a enhancement that we can prevent mozilla crash when it is cheated :-)
I don't expect mozilla to do anything meaningful (except not crash), but I consider a bug that allows any web site author to purposely crash the user's browser a serious DoS vulnerability. Of course it doesn't do much damage in a client application like a browser, but one of the goals of the Mozilla project is that it can be used for many other purposes than web browsing.
This is for error handling
Whiteboard: redesign? → redesign, error-handling
This is on RedHat 8.0 (Linux kernel 2.4.18-24.8.0) Copied j2sdk1.4.1_02/jre/plugin/i386/ns610/libjavaplugin_oji.so to mozilla/plugins. "Help/About Plug_ins" shows plug_in as enabled.
The "Simple HTML page that crashes browser" attachment that was just added doesn't crash Mozilla for me, it just shows a red cross in the upper-left corner of the applet. Mozilla build 2003021000, j2re1.4.1 on Mandrake. But the "Random binary garbage that crashes Mozilla" testcase still makes Mozilla crash.
Handling something with the wrong content type is something every other part of Mozilla can do. If you load a random binary file served as text/html, Mozilla will beat itself silly trying to determine the characterset of the file, but it won't crash and will eventually return control back to the user. In cases where it does have problems, we try to fix them: bug 161336 and bug 187654
I can no longer reproduce the bug in mozilla-1.4-2mdk (Mandrake's build) with j2re 1.4.2. Is it working for everyone else too? In that case I guess it should be marked as FIXED in that case. In stead of crashing it now simply displays a red cross in the upper left corner, and that looks like correct behavior to me.
Assignee: joshua.xia → kyle.yuan
Status: ASSIGNED → NEW
I have the same problem with x-java-vm applications. A good example is yahoo games.
Dan, could you explain a little more about your problem with yahoo games and how it's related to this bug? I can play yahoo games without problem.
mass reassign to Alfred
Assignee: zhayupeng → alfred.peng
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 Java(TM) 2 Platform Standard Edition 5.0 Update 10 Java Plug-in 1.5.0_10 for Netscape Navigator (DLL Helper) tested on both testcases, URL: gives 404
WFM on Ubuntu 8.04 with Firefox 3.0.10 and Java 1.6 update 7
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
I'm afraid I can still reproduce this bug. It may be a completely different bug from the one I originally filed seven years ago, but it still makes Firefox crash. Steps to reproduce. 1. Click the first attachment above <https://bugzilla.mozilla.org/attachment.cgi?id=107341>. 2. Wait for the Java loading screen to appear (the nice spinning blue colours). 3. Press Back in the browser. 4. Press Forward in the browser. Firefox crashes every time I perform those steps. I am running Firefox version 3.0.10+nobinonly-0ubuntu0.9.04.1 on Ubuntu 9.04 x86_64 with sun-java6-plugin 6-13-1.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
so, as long as java is calling exit(), it's java's fault. please file a bug with sun. it might get fixed faster (or not).
OJI has been discontinued and Java now runs out-of-process, so this stuff has probably changed a lot. This bug has no info about current software versions, please file a new bug for new issues or reopen this one with current info, including a crash signature if it still happens and move it to a component outside of graveyard.
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago → 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.