JDK-6589720 : Browser lockup on X11 platforms
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u4
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: generic
  • Submitted: 2007-08-06
  • Updated: 2010-09-17
  • Resolved: 2008-01-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u10 b02Fixed 7Fixed
Related Reports
Relates :  
JDK-6589714 - Incorrect synchronization in AppletClassLoader causes deadlock
Description
###@###.### indicates that with the 6u4 early access build, running an arbitrary applet on Linux (and, presumably, Solaris) locks up the web browser completely. The browser does not repaint and must be manually killed:

-----
The same "firefox dies but the applet keeps running" symptom can be reproduced with the Chess game at java.com:

http://java.com/en/games/desktop/chess.jsp

Click "TRY IT NOW", then click "Play as Guest". This will start the Applet. After a while (sometimes right away), the browser will stop responding to all input and repaint events and will have to be killed. The Applet continues to run. This happens on Linux, but not on Windows Vista. I didn't try any other OS.
-----
Comments
EVALUATION This problem is similar to what found in 6521732 whose fix in already in for 7.0 and 6u2. (http://web-east.east/deployment/www/webrevs/dp144265/7.0/6521732/webrev/) For FF JPI Solaris/Linux, we associate the PluginInstance and PluginObject with an ID. The access of this ID isn't thread safe. When mismatched IDs happened (as in case of multiple applets), it causes lockup of several EDT in the system. In 6521732, I've fixed the problem in the native side. However, a mirrored problem exists in Java side as well (recall that Unix JPI is out-of-proc with java stuffs running in java_vm process), and it shows up with changes made in 6u4 (thanks to the 3d demos)
10-08-2007