Here is an entry from my nightly analysis report:

New JDI_REGRESSION failures (from 2009.01.07)
* com/sun/jdi/ExclusiveBind.java
        This test failed due to

            ERROR: transport error 202: handshake failed - connection prematurally closed
            ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
            JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [../../../src/share/back/debugInit.c:708]
            FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)

        on Solaris SPARC-64 Server VM (machine meena). This failure
        mode is covered by the following bug:

            6303969 4/4 JDWP: Socket Transport handshake fails rarely
                        on InstancesTest.java

        I will copy this entry to 6303969.

        This instance of the 6303969 failure mode is obscured by the
        nature of the test which is to try and launch two debuggees
        using the same port serially. The error messages from the
        expected failure are mixed in with the error messages from the
        6303969 failure mode.

        In addition to the 6303969 failure mode, there is a timing
        problem with the test. Here is the main part of the test:

            140 // launch the first debuggee
            141 Process process1 = launch(address, true, "HelloWorld");
            142
            143 // give first debuggee time to suspend
            144 Thread.currentThread().sleep(5000);
            145
            146 // launch a second debuggee with the same address
            147 Process process2 = launch(address, false, "HelloWorld");
            148
            149 // get exit status from second debuggee
            150 int exitCode = process2.waitFor();
            151
            152 // clean-up - attach to first debuggee and resume it
            153 AttachingConnector conn = (AttachingConnector)
                     findConnector("com.sun.jdi.SocketAttach");
            154 Map conn_args = conn.defaultArguments();
            155 Connector.IntegerArgument port_arg =
            156 (Connector.IntegerArgument)conn_args.get("port");
            157 port_arg.setValue(port);
            158 VirtualMachine vm = conn.attach(conn_args);
            159 vm.resume();

        The sleep between the launch of the first debuggee and the
        attempted launch of the second debuggee doesn't scale and it
        also makes the assumption that the first debuggee actually
        launched. The block from line 152 -> line 158 should be moved
        after the launch of the first debuggee. The resume of the first
        debuggee (line 159) needs to remain after the the attempt to
        launch the second debuggee.

        The sleep can be replaced by something like:

            // The first event is always a VMStartEvent, and it is
            // always in an EventSet by itself. Wait for it.
            EventSet evtSet = vm.eventQueue().remove();
            for (Event event: evtSet) {
                if (event instanceof VMStartEvent) {
                    break;
                }
                throw new RuntimeException("Test failed -"
                    + " debuggee did not start properly");
            }

        I grabbed the above code blob from Jim's fix for:

            6454193 4/4 JTREG test bug: 'com/sun/jdi/RunToExit.java'
                        fails with timeout