United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6661386 Passing illegal command-line arguments to applets causing browser hangs
6661386 : Passing illegal command-line arguments to applets causing browser hangs

Details
Type:
Bug
Submit Date:
2008-02-11
Status:
Closed
Updated Date:
2010-09-08
Project Name:
JDK
Resolved Date:
2008-03-25
Component:
deploy
OS:
windows
Sub-Component:
plugin
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u10

Related Reports
Relates:
JDK-6651507 - Implement named pipe transport for Windows
Relates:
JDK-6678865 - Long command lines or applet parameter lists break new plug-in on Windows

Sub Tasks

Description
Passing illegal command-line arguments to applets via the java_arguments parameter is causing the browser to hang. The reason is the introduction of the named pipe transport for the Windows platform in 6651507 and more specifically hangs in the underlying Windows APIs. It appears that the ConnectNamedPipe API, when used in blocking mode as we do, will block until the other side opens the named pipe, and if invalid command-line arguments prevent the attached JVM from starting, then we will hang forever waiting for it to connect, which it never will. Additionally, it appears that the DisconnectNamedPipe and even the CloseHandle APIs hang while a thread is stopped in ConnectNamedPipe, so it is necessary to work around this problem.

Comments
SUGGESTED FIX

http://sa.sfbay.sun.com/projects/deployment_data/6u10/6661386.1
testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6661386/
2008-02-12 
EVALUATION

We use the Windows Named Pipe APIs in blocking mode, and in this mode
some of the APIs such as ConnectNamedPipe, DisconnectNamedPipe and
even CloseHandle can block indefinitely. If the server never receives
a connection from the client, it will hang in ConnectNamedPipe, and
even if a second thread attempts to shut down the pipe via
CloseHandle, the second thread will hang indefinitely.

Worked around this issue by moving connection and shutdown calls on
the server side on to separate threads. In order for higher level
layers to work (for example, the JVM restarting mechanism when illegal
command-line arguments are specified), the initial writes must not
block, and their state must not be lost. Added workarounds for this
issue.
2008-02-12


Hardware and Software, Engineered to Work Together