JDK-6396012 : [vermillion 06]Firefox hangs after java applet loading failed
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 5.0u6,6
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: solaris,windows_xp
  • CPU: x86
  • Submitted: 2006-03-09
  • Updated: 2010-09-29
  • Resolved: 2007-12-11
Description
Snv b34, vermillion b06, jdk1.5.0_06-04

reproduce steps:
1. start firefox
2. load an applet (e.g. http://quarterfinal.prc/demoapplet/testcase/NewApplet.html). This applet can not be loaded successfully, the class file is missing.
3. right click the mouse on the applet area to open the Java Console
4. monitor the cpu usage of the firefox process by prstat, the cpu usage increaces dramatically. and the browser hangs.

Sometimes this bug can be reproduced after repeating these steps 2 or 3 times.
-- New report from another customer ...

FULL PRODUCT VERSION :
java version "1.6.0-beta2"
Java(TM) SE Runtime Environment (build 1.6.0-beta2-b84)
Java HotSpot(TM) Client VM (build 1.6.0-beta2-b84, mixed mode, sharing)

Java Plug-in 1.6.0-beta2
Using JRE version 1.6.0-beta2 Java HotSpot(TM) Client VM

ADDITIONAL OS VERSION INFORMATION :
Windown XP SP2 (Czech)

A DESCRIPTION OF THE PROBLEM :
After Applet throws an exception (error), it gets reported nicely in a popup window, but then Firefox hangs forever.

Tested with Firefox 1.5.0.4 and Mustang b84 (it did that in earlier builds too).


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Make an applet throw an exception - be it simple missing class file for the Applet, or a RuntimeException thrown in a Thread started by the Applet, whatever.

Here is the simplest test case for the problem - a missing applet class:

--------- crash1.html -------------------------------------------
<html>
   <body>
     <applet code="nonexisting.class" width=1 height=1>
     </applet>
   </body>
</html>



EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Firefox should recover nicely, possibly not showing the failing applet.
Internet Explorer, for example, generates a "java.lang.ClassNotFoundException: nonexisting.class" and then returns control to the user.

ACTUAL -
Firefox will hang badly. Will not refresh, you can still close the browser window but the process will still hang in the memory, preventing you from starting a new browser. You have to kill firefox.exe from the task manager.

REPRODUCIBILITY :
This bug can be reproduced always.
Turns out this is (probably) a Gecko bug. See
http://bugzilla.mozdev.org/show_bug.cgi?id=16670 for more information.

it can be reproduced under FireFox 2.0.0.3 (which is the latest) but it's
gone in FireFox 3.0 alpha 2. One would hope they fold in this fix into
FireFox 2.x in the near future.

Comments
EVALUATION Though this problem is not reproducible by SQE and myself, bug is confirmed to be on the browser side and has been fixed in FF3 line (but not FF2.0). See comment from Ingrid: Turns out this is (probably) a Gecko bug. See http://bugzilla.mozdev.org/show_bug.cgi?id=16670 for more information. it can be reproduced under FireFox 2.0.0.3 (which is the latest) but it's gone in FireFox 3.0 alpha 2. One would hope they fold in this fix into FireFox 2.x in the near future.
11-12-2007

EVALUATION I asked ###@###.### from SQE to verify this bug for me with machines in the lab. The result is the same as what I got: no problem to click right on the "gray box" to launch Java Console at all. No memory leak seen and no hang was observed. According to SQE, this is the scenario that they tested very often with FF. Jitender was surprised that if such problem exists and was not caught by SQE. I think there's problem with your systems. Please re-verify your test systems. This bug will have to be closed, as it's not reproducible and currently under the EC radar for 6.0.
29-08-2006

EVALUATION Problem is not reproduceable. Will close out this bug.
13-04-2006

EVALUATION I tried the testcase with 1.5.0_07 B2 with FF 1.5 and repeated the steps mentioned many times. I do not see any FF hang issue at all. Observing the memory usage when the Java Console is repeatedly opened then closed, I do see some small fluctuation - memory usage increase when Java Console is opened then decrease "periodically". This is not a memory leak problem, for several things that I want to point out: 1) Memory usage increase when a new Java Console is opened is very small (~10KB). 2) Memory usage decreases "periodically" depended on when the GC is kicked in. When GC kicked in, it takes care of freeing dynamically allocated memory from the previous instance of the Java Console that is no longer referenced, and hence, memory usage decreases. You can see this activity by specify "-verbose:gc" for the jre before running this applet. This would print GC activity information at every collection when you run the applet and repeatedly open and close the Java Console. 3) Overall the total memory usage stay pretty constant around ~45M on my system. Therefore, I would not consider this a memory leak issue. You can play around with -XX:MinHeapFreeRatio=, -XXMaxHeapFreeRatio=, -Xms=, -Xmx=, to tune your GC. But unless you know what you're doing, otherwise, you can create inadvertent affect on your application performance. In this case, memory stays pretty constant after stable (GC kicks in), so I'd suggest to leave it as it. I'm more concerned about the "hang" problem mentioned. As said, I could not reproduce this hang problem. Please retry with 1.5.0_07 B2 and 1.6.0 latest build. For latest promoted 1.5.0 update release build and 1.6.0 latest build, if youre within Sun, check out onestop/jdk from koori.sfbay. I will wait for status update from you for 2 more weeks before closing out this bug.
24-03-2006