Bug ID: JDK-6668033 New plugin applet freezes the browser occasionally

JDK-6668033 : New plugin applet freezes the browser occasionally

Type: Bug
Component: deploy
Sub-Component: plugin
Affected Version: 6u1,6u10

Priority: P3
Status: Closed
Resolution: Fixed
OS: generic,windows
CPU: generic,x86

Submitted: 2008-02-26
Updated: 2010-09-08
Resolved: 2008-05-28

Versions (Unresolved/Resolved/Fixed)

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
6u10 b21Fixed

Related Reports

Duplicate :	JDK-6668195 - JNLP-OOPP: SingleInstanceService is not working correctly on IE7 and FF3 on windows
Duplicate :	JDK-6566071 - Java Web Start doesn't check time stamp of nested JNLP files
Duplicate :	JDK-6650343 - Unable to read properties value with spaces specified against java_arguments
Duplicate :	JDK-6665588 - JNLP-OOPP: Applets fails to load if is specified inside the JNLP file
Duplicate :	JDK-6662428 - BasicServiceImpl.showDocument() needs to be overridden in JNLP support for new plug-in
Relates :	JDK-6678349 - Regression: speed-trap.com dashboard doesn't load
Relates :	JDK-6673621 - Can not launch Bugster with current nightly build

Description

Occasional test applets, using th enew plugin freezing IE on windows.

PIT build(dated-Feb22) 

Windows

IE

+++

2008-02-26 10:07:00
Full thread dump Java HotSpot(TM) Client VM (11.0-b11 mixed mode, sharing):

"JRE 1.6.0.10 Heartbeat Thread" prio=6 tid=0x07377800 nid=0x101c waiting on condition [0x0766f000..0x0766fb94]
�� ��java.lang.Thread.State: TIMED_WAITING (sleeping)
����������������at java.lang.Thread.sleep(Native Method)
����������������at sun.plugin2.main.server.JVMInstance$HeartbeatThread.run(Unknown Source)

�� ��Locked ownable synchronizers:
����������������- None

"JRE 1.6.0.10 Worker Thread" prio=6 tid=0x07386800 nid=0xe78 in Object.wait() [0x07b7f000..0x07b7fc14]
�� ��java.lang.Thread.State: TIMED_WAITING (on object monitor)
����������������at java.lang.Object.wait(Native Method)
����������������- waiting on <0x25a501e0> (a sun.plugin2.message.Queue)
����������������at sun.plugin2.message.Queue.waitForMessage(Unknown Source)
����������������- locked <0x25a501e0> (a sun.plugin2.message.Queue)
����������������at sun.plugin2.message.Pipe.receive(Unknown Source)
����������������at sun.plugin2.main.server.JVMInstance$WorkerThread.run(Unknown Source)

�� ��Locked ownable synchronizers:
����������������- None

"JRE 1.6.0.10 Output Reader Thread" prio=6 tid=0x07385000 nid=0x1558 runnable [0x07a7f000..0x07a7fc94]
�� ��java.lang.Thread.State: RUNNABLE
����������������at java.io.FileInputStream.readBytes(Native Method)
����������������at java.io.FileInputStream.read(Unknown Source)
����������������at sun.plugin2.main.server.JVMInstance$StreamMonitor.run(Unknown Source)
����������������at java.lang.Thread.run(Unknown Source)

�� ��Locked ownable synchronizers:
����������������- None

"JRE 1.6.0.10 Output Reader Thread" prio=6 tid=0x07383c00 nid=0xa8 runnable [0x0797f000..0x0797fd14]
�� ��java.lang.Thread.State: RUNNABLE
����������������at java.io.FileInputStream.readBytes(Native Method)
����������������at java.io.FileInputStream.read(Unknown Source)
����������������at java.io.BufferedInputStream.fill(Unknown Source)
����������������at java.io.BufferedInputStream.read1(Unknown Source)
����������������at java.io.BufferedInputStream.read(Unknown Source)
����������������- locked <0x25a53348> (a java.io.BufferedInputStream)
����������������at java.io.FilterInputStream.read(Unknown Source)
����������������at sun.plugin2.main.server.JVMInstance$StreamMonitor.run(Unknown Source)
����������������at java.lang.Thread.run(Unknown Source)

�� ��Locked ownable synchronizers:
����������������- None

"Thread-0" prio=6 tid=0x07382c00 nid=0x1720 runnable [0x0787f000..0x0787fd94]
�� ��java.lang.Thread.State: RUNNABLE
����������������at java.lang.ProcessImpl.waitFor(Native Method)
����������������at sun.plugin2.jvm.JVMLauncher$JVMWatcher.run(Unknown Source)
����������������at java.lang.Thread.run(Unknown Source)

�� ��Locked ownable synchronizers:
����������������- None

"Java Plug-In Pipe Worker Thread (Server-Side)" prio=6 tid=0x07381000 nid=0x10a4 runnable [0x0776f000..0x0776fa14]
�� ��java.lang.Thread.State: RUNNABLE
����������������at sun.plugin2.os.windows.Windows.ReadFile0(Native Method)
����������������at sun.plugin2.os.windows.Windows.ReadFile(Unknown Source)
����������������at sun.plugin2.ipc.windows.WindowsNamedPipe.read(Unknown Source)
����������������at sun.plugin2.message.transport.NamedPipeTransport$SerializerImpl.read(Unknown Source)
����������������at sun.plugin2.message.transport.NamedPipeTransport$SerializerImpl.readByte(Unknown Source)
����������������at sun.plugin2.message.AbstractSerializer.readInt(Unknown Source)
����������������at sun.plugin2.message.transport.SerializingTransport.read(Unknown Source)
����������������at sun.plugin2.message.Pipe$WorkerThread.run(Unknown Source)

�� ��Locked ownable synchronizers:
����������������- None

"traceMsgQueueThread" daemon prio=6 tid=0x06af8800 nid=0xa78 in Object.wait() [0x0736f000..0x0736fb94]
�� ��java.lang.Thread.State: WAITING (on object monitor)
����������������at java.lang.Object.wait(Native Method)
����������������- waiting on <0x25a54610> (a java.util.ArrayList)
����������������at java.lang.Object.wait(Object.java:485)
����������������at com.sun.deploy.util.Trace$TraceMsgQueueChecker.run(Unknown Source)
����������������- locked <0x25a54610> (a java.util.ArrayList)
����������������at java.lang.Thread.run(Unknown Source)

�� ��Locked ownable synchronizers:
����������������- None

"Low Memory Detector" daemon prio=6 tid=0x06aa4c00 nid=0xcf0 runnable [0x00000000..0x00000000]
�� ��java.lang.Thread.State: RUNNABLE

�� ��Locked ownable synchronizers:
����������������- None

"CompilerThread0" daemon prio=10 tid=0x06a9e400 nid=0xa00 waiting on condition [0x00000000..0x0706f640]
�� ��java.lang.Thread.State: RUNNABLE

�� ��Locked ownable synchronizers:
����������������- None

"Attach Listener" daemon prio=10 tid=0x06a9cc00 nid=0x12f4 waiting on condition [0x00000000..0x00000000]
�� ��java.lang.Thread.State: RUNNABLE

�� ��Locked ownable synchronizers:
����������������- None

"Signal Dispatcher" daemon prio=10 tid=0x06a9b800 nid=0x1108 runnable [0x00000000..0x00000000]
�� ��java.lang.Thread.State: RUNNABLE

�� ��Locked ownable synchronizers:
����������������- None

"Finalizer" daemon prio=8 tid=0x06a96c00 nid=0x11a4 in Object.wait() [0x06d6f000..0x06d6fa94]
�� ��java.lang.Thread.State: WAITING (on object monitor)
����������������at java.lang.Object.wait(Native Method)
����������������- waiting on <0x25a54838> (a java.lang.ref.ReferenceQueue$Lock)
����������������at java.lang.ref.ReferenceQueue.remove(Unknown Source)
����������������- locked <0x25a54838> (a java.lang.ref.ReferenceQueue$Lock)
����������������at java.lang.ref.ReferenceQueue.remove(Unknown Source)
����������������at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)

�� ��Locked ownable synchronizers:
����������������- None

"Reference Handler" daemon prio=10 tid=0x06a92000 nid=0x10d8 in Object.wait() [0x06c6f000..0x06c6fb14]
�� ��java.lang.Thread.State: WAITING (on object monitor)
����������������at java.lang.Object.wait(Native Method)
����������������- waiting on <0x25a50148> (a java.lang.ref.Reference$Lock)
����������������at java.lang.Object.wait(Object.java:485)
����������������at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)
����������������- locked <0x25a50148> (a java.lang.ref.Reference$Lock)

�� ��Locked ownable synchronizers:
����������������- None

"main" prio=6 tid=0x02ba9c00 nid=0x16dc runnable [0x0013d000..0x0013e674]
�� ��java.lang.Thread.State: RUNNABLE
����������������at sun.plugin2.main.server.WindowsHelper.runMessagePump0(Native Method)
����������������at sun.plugin2.main.server.WindowsHelper.runMessagePump(Unknown Source)
����������������at sun.plugin2.main.server.IExplorerPlugin.runMessagePump(Unknown Source)
����������������at sun.plugin2.main.server.IExplorerPlugin.runMessagePump(Unknown Source)
����������������at sun.plugin2.main.server.IExplorerPlugin.access$400(Unknown Source)
����������������at sun.plugin2.main.server.IExplorerPlugin$1.waitForSignal(Unknown Source)
����������������at sun.plugin2.main.server.ResultHandler.waitForResult(Unknown Source)
����������������at sun.plugin2.main.server.AbstractPlugin.getScriptingObjectForApplet(Unknown Source)
����������������at sun.plugin2.main.server.IExplorerPlugin.getScriptingObjectForApplet(Unknown Source)

�� ��Locked ownable synchronizers:
����������������- None

"VM Thread" prio=10 tid=0x06a90800 nid=0x10cc runnable 

"VM Periodic Task Thread" prio=10 tid=0x06ab8400 nid=0x1684 waiting on condition 

JNI global references: 710
Jitender could reproduce this freeze as follows:

This single instance testcase is haning for me on IE6 nad IE7.
http://nicole1.sfbay.sun.com:8080/plugin_tests/JNLPSupport/applets/AppletBasics/JNLPSingleInstanceService1-jnlp-applet-rel1.html

Windows, IE6 and IE7

+++

GNU/Linux x86 FF3, after fix for CR 6665008 not reproducable.

Comments

SUGGESTED FIX SingleInstance Browser Freeze: - JNLP2Manager, Plugin2Manager - In case of an already existent instance, send a proper appletAbort message to the server. +++ JREInfo bug introduced in CR 6665008 - addJRE uses 'findByPath' to determine if the to be added instance is a dublicate - findByPath did not consider the '_system' attribute, therefor a new JREInfo could not exist in the user properties. Therefor JREInfo would not be stored within the deployment.property, and a relaunch would not be successfull. +++ Synced OOPP JNLP2Manager with JAVAWS Launcher.java - Launcher.java - using MatchJREIf properly - branch cleanups ;-) - JNLP2Manager.downloadJREResource() - pre JRE download: - respect Config.AUTODOWNLOAD_MODE_NEVER - use defaultUrl 'Config.JAVAWS_JRE_INSTALL_KEY' for platform version, where location==null - add SecureStaticVersioning.promptRequired(..) - using DownloadEngine.getAvailableVersion(..) - JNLP2Manager - removed dead cases: - isInstaller - isImport - isSilent - added local application properties _lap +++ JNLP JREDesc select - Consolidating LaunchSelection.MatchJREIf - removing sun.plugin2.applet.Plugin2MatchJRE - common implementation is com.sun.javaws.DefaultMatchJRE. - LaunchSelection - Complete traversal through the whole JNLP graph - MatchJREIf / DefaultMatchJRE - Now designed to - start traversal - digest all JREDesc while traversing - end traversal - Results: - JVMParameters for the desired JVM arguments, which are accumulated from all JREDesc: - max heapsize wins - unique arguments - chronological order from inside to outside, the JNLP graph - JREInfo for the desired and installed JRE version - the highes JRE version required/allowed in the JNLP graph - isRunningJVMSatisfying() if the running JREInfo satisfy us, i.e. JRE version and jvm arguments - sun.plugin2.util.BufferUtil moved to com.sun.deploy.util.BufferUtil - sun.plugin2.util.ArgUtil moved into com.sun.deploy.util.JVMParameters - sun.plugin2.util.JVMParameters moved to com.sun.deploy.util.JVMParameters - JVMParameters.Property Presents a system property hashed by the key only. This allows us to make properties unique by their keys. - JVMParameters.ArgumentSet - Using com.sun.deploy.util.OrderedLinkedHashSet and removing old entries before adding them, which gives us all arguments in the chronological order without duplicated. - systemProperties is JVMParameters.Property, so no double properties anymore. - Adding static homeJVMParameters, holding the running JVM's parameter. This shall be set by the launching JVM entity. - OrderedLinkedHashSet package com.sun.deploy.util; Implements pure Java 1.3 sort of LinkedHashSet, which fully implements List as well. It uses HashMap and LinkedList. It's 'add(Object o)' will move a pre-existing object to the end of the list, and therefor is very strict to it's order. +++ JNLP relative codebase - Since the new semantics of relative codebase, always use the jnlp file's basedir as the fallback codebase, i.e. if the jnlp file doesn't contain any codebase. We don't just use the parents codebase... - codebase from documentbase must strip the filename, i.e. the basedir. True is for http://aaa.org/ html/a.html -> ../jnlp/a.jnlp jnlp/a.jnlp (no codebase) codebase = http://aaa.org/jnlp/ html/a.html -> ../jnlp/a.jnlp jnlp/a.jnlp (codebase="codebasedir") codebase = http://aaa.org/jnlp/codebasedir/ Added 2 more rel codebase tests .. - Organized all tests in grouped html pages ..

02-03-2008

EVALUATION The browser freezes only occures for the single instance services and on this browser. CR 6665008 should have already fixed the worst, but must be still verified

28-02-2008

EVALUATION Cause of the browser freeze is the LiveConnect (LC) communication with the server, where the browser waits forever for a LC response.

26-02-2008