United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6589720 Browser lockup on X11 platforms
JDK-6589720 : Browser lockup on X11 platforms

Details
Type:
Bug
Submit Date:
2007-08-06
Status:
Closed
Updated Date:
2010-09-17
Project Name:
JDK
Resolved Date:
2008-01-17
Component:
deploy
OS:
linux
Sub-Component:
plugin
CPU:
generic
Priority:
P1
Resolution:
Fixed
Affected Versions:
6u4
Fixed Versions:
6u10 (b02)

Related Reports
Backport:
Relates:

Sub Tasks

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)
                                     
2007-08-10



Hardware and Software, Engineered to Work Together