Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: neutral (athena.apache.org: 195.212.29.140 is neither permitted
 nor denied by domain of mark.hindess@googlemail.com)
Message-Id: <200909112213.n8BMDlFF027083@d06av03.portsmouth.uk.ibm.com>
From: "Mark Hindess" <mark.hindess@googlemail.com>
To: "Apache Harmony Dev List" <dev@harmony.apache.org>
Subject: [classlib] java.io.DataOutputStream behaviour doesn't match RI
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 11 Sep 2009 23:13:41 +0100


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).