United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6678865 Long command lines or applet parameter lists break new plug-in on Windows
JDK-6678865 : Long command lines or applet parameter lists break new plug-in on Windows

Details
Type:
Bug
Submit Date:
2008-03-22
Status:
Closed
Updated Date:
2010-09-08
Project Name:
JDK
Resolved Date:
2008-06-14
Component:
deploy
OS:
solaris
Sub-Component:
plugin
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u10 (b23)

Related Reports
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
On Unix, the minimum POSIX command line length is 4096.
Having our extreme test case
http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6676879/JNLPLongProperties0.3.rel.html,
which tries to assemble considerable insane long JVM startup arguments.
The client message serializer get's out of order with the message stream.
It digests the JMVID, including the very long JVM argument list,
which might already breaks the serializer state.
Then it recognizes the following StartAppletMessage ID, 
but bails out then immediatly, since all followup bytes are misinterpreted,
or out of order.

This behavior was discovered while adding the mentioned stress commandline test
for CR 6676879, which adds validation code in this respect.
The fix for 6678929 fixed this problem on Unix platforms. Apparently there was a bug with the SocketTransport used to communicate between the browser-side code and the attached JVM that was the root cause. On Unix platforms, Unix domain sockets are now used, which are analogous to the named pipes currently used on the Windows platform.

There appears to be a residual bug in the named pipe implementation on Windows (see 6651507) causing breakage of the transport when a large amount of data is sent over. The following forum thread highlights this issue:

http://forums.java.net/jive/thread.jspa?threadID=39013&tstart=0

Investigating this with high priority as it indicates a deep problem.

                                    

Comments
WORK AROUND

We currently restrict the maximum command line length to 2047,
which is the maximum for Windows 2k and NT4.
                                     
2008-03-22
EVALUATION

See suggested fix ..
                                     
2008-04-09
SUGGESTED FIX

Dropping the non-blocking SocketTransport for Unix,
and using the unix AF_UNIX sockets to implementent the unix variant
of NamedPipe (Unix Domain Sockets).

This is done in the performance fix, see: CR 6678929
                                     
2008-04-09
EVALUATION

When the named pipe transport was implemented for Windows under
6651507, some deadlocks were discovered due to poor behavor of the
Windows APIs. Workarounds were developed at the time involving the
addition of more threads, as well as an initial write buffer to hold
the results of the first few messages from the browser to the client
attached JVM, which was found to be necessary at one point in the
development to avoid deadlocks.

Investigation of the customer's report for this bug indicated that
this initial write buffer was getting corrupted. Initially we believed
that the data being sent over the named pipe was being corrupted, but
detailed investigation revealed that this was not the case. The
corruption occurred at the point when the initial write buffer filled
up and we were forced to wait for a connection from the client in
order to flush it to the named pipe.

Thanks to ###@###.### for the idea to completely remove the
initial write buffer, which is possible at this time because the
background connection thread already present handles the deadlock case
the initial write buffer was originally intended to fix. My original
fix involved expanding the initial write buffer to a list of buffers,
which also solved the problem but added significant complexity, now
understood to be unnecessary.

Some other minor cleanups were made in the WindowsNamedPipe
implementation in the spirit of robustness although they were not the
root cause of this bug.

While investigating this bug, two other issues were uncovered. First,
the filtering of disabled JREs in the JVMManager was occasionally
removing the wrong JRE in the case that two different copies of the
same JRE were present in deployment.properties, one disabled, one
enabled. Second, there was a lurking synchronization bug in the
SerializingTransport base class where subclasses could inadvertently
break the critical synchronization around serialization of messages.
This is very likely the reason the earlier SocketTransport was failing
on the same test case.

Also deleted a few files that were intended to have been deleted in
previous putbacks.

This fix was tested with the regression tests for related bugs 6659079
and 6661386 as well as a new targeted test case.
                                     
2008-04-14
SUGGESTED FIX

webrev: http://sa.sfbay.sun.com/projects/deployment_data/6u10/6678865.0
testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6678865/
                                     
2008-04-14



Hardware and Software, Engineered to Work Together