I've checked in a fix for this in r814380. I'll do a merge to java6
shortly.
-Mark.
In message <200909112213.n8bmdlff027...@d06av03.portsmouth.uk.ibm.com>,
"Mark Hindess" writes:
>
> I am trying to work through the JDWP java6 branch test failures
> (so is Oliver). I see quite a lot of intermittent failures on
> Linux[0]. I think they are mostly caused by failures at the time
> when the socket used for synchronising the debuggee/debugger
> is being closed. The sychronisation is simply one end calling
> "DataOutputStream.writeUTF("continue"); DataOutputStream.flush();" and
> the other end trying to do DataInputStream.readUTF().
>
> When running on the RI, the tests pass consistently. Strace of the RI
> shows the writeUTF making syscalls like:
>
> send(10, "\0\10continue", 10, 0) = 10
> close(10) = 0
>
> where as our implementation does:
>
> send(58, "\0\10", 2, 0) = 2
> send(58, "continue", 8, 0) = 8
> close(58) = 0
>
> Examining the packet dump for the socket shows a packet containing the
> length ('\0\10') followed by a RST packet as the socket is closed but no
> packet containing the "continue" text. So, the "continue" is lost with
> the result that the other end reads the length then loops waiting for
> the message until the test timeout is reached.[1]
>
> I think it would probably be useful if we fixed our implementation to
> have the same behaviour as the RI.
>
> Regards,
> Mark.
>
> [0] I'm using org.apache.harmony.jpda.tests.jdwp.MultiSession.RefTypeIDTest
> for testing but there are plenty of intermittently failing tests to
> choose from.
>
> [1] I wonder why doesn't it see the socket close and bail out? This is
> probably another bug (perhaps with the framework).
