The failure mode in the previous entry:

java.net.SocketException: Connection reset by peer: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
at java.net.SocketOutputStream.write(SocketOutputStream.java:141)
at BadHandshakeTest.main(BadHandshakeTest.java:169)

reminds me of the failure mode described in the following bug:

    6432567 4/3 PIT : com/sun/jdi/BadHandshakeTest.java fails due to
                java.net.ConnectException

6432567 is marked as integrated in JDK7-B72. Here is the changeset:

Changeset: 87a2ef2439bc
Author: alanb
Date: 2009-09-04 22:22 +0100
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/87a2ef2439bc

6432567: PIT : com/sun/jdi/BadHandshakeTest.java fails due to java.net.ConnectException
Reviewed-by: tbell, ohair, dcubed, andrew

! src/share/transport/socket/socketTransport.c
! test/com/sun/jdi/BadHandshakeTest.java

I verified that changeset 87a2ef2439bc was pushed for JDK7-B72 which
was promoted on 2009.09.17.
The following SDK/JDK test is failing intermittently
during nightly testing:

    com/sun/jdi/BadHandshakeTest.java

Here is the URL for a recent failure:

http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2010-09-08/RT_Baseline/javase/windows-amd64/server/mixed/windows-amd64_javase_server_mixed_JT_JDK_com_sun_jdi/analysis.html

This particular failure occurred on machine 'vm-v20z-16' which is
running Win-AMD64.

Here is a snippet of the .jtr file:

#section:main
----------messages:(3/122)----------
command: main BadHandshakeTest
reason: User specified action: run main BadHandshakeTest
elapsed time (seconds): 960.0
----------System.out:(3/919)*----------
-- Added debuggeeVM options from file C:\\local\\38033.JDK7.NIGHTLY.VM+windows-amd64_javase_server_mixed_JT_JDK_com_sun_jdi\\results\\workDir\\classes\\com\\sun\\jdi\\@debuggeeVMOptions: -Xmixed -server -XX:-PrintVMOptions -XX:+StartAttachListener -Dsun.jvm.hotspot.runtime.VM.disableVersionCheck=1 -XX:DefaultMaxRAMFraction=8 -XX:+IgnoreUnrecognizedVMOptions -XX:+UseCompressedOops
Starting: C:\\local\\common\\jdk\\baseline\\windows-amd64\\jre\\bin\\java -classpath C:\\local\\38033.JDK7.NIGHTLY.VM+windows-amd64_javase_server_mixed_JT_JDK_com_sun_jdi\\results\\workDir\\classes\\com\\sun\\jdi -Xmixed -server -XX:-PrintVMOptions -XX:+StartAttachListener -Dsun.jvm.hotspot.runtime.VM.disableVersionCheck=1 -XX:DefaultMaxRAMFraction=8 -XX:+IgnoreUnrecognizedVMOptions -XX:+UseCompressedOops -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=1716 Exit0
Listening for transport dt_socket at address: 1716
----------System.err:(16/1007)----------
java.net.SocketException: Connection reset by peer: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
at java.net.SocketOutputStream.write(SocketOutputStream.java:141)
at BadHandshakeTest.main(BadHandshakeTest.java:169)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:613)
at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
at java.lang.Thread.run(Thread.java:717)

JavaTest Message: Test threw exception: java.net.SocketException: Connection reset by peer: socket write error
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.net.SocketException: Connection reset by peer: socket write error
result: Error. Program `C:\local\common\jdk\baseline\windows-amd64\bin\java' interrupted! (timed out?)


test result: Error. Program `C:\local\common\jdk\baseline\windows-amd64\bin\java' interrupted! (timed out?)


Here is a URL for a Win32 failure:

http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2010-08-25/Comp_Baseline/javase/windows-i586/server/mixed/windows-i586_javase_server_compd_JT_JDK_com_sun_jdi/analysis.html

However, the test machine is 'vm-v20z-18' which is also running Win-AMD64.


Nightly search found failures of these test all the way back to 2010.02.06.
I checked all the non-WinAMD64 failures. For the Win32 failures, all of
the platform OSes were Win-AMD64. For the Linux and Solaris failures, there
were other issues (command line options, assertion failures) that were not
related to this failure mode.

Here is the URL of the oldest failure:

http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2010-02-06/Main_Baseline/javase/windows-amd64/server/mixed/windows-amd64_server_mixed_JDI_REGRESSION/analysis.html