JDK-6661386 : Passing illegal command-line arguments to applets causing browser hangs
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: generic
  • Submitted: 2008-02-11
  • Updated: 2010-09-08
  • Resolved: 2008-03-25
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 b13Fixed
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
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/
12-02-2008
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.
12-02-2008