RFR: 8004126: TEST_BUG: com/sun/jdi/BadHandshakeTest.java fails intermittently
jaroslav.bachorik at oracle.com
Thu Nov 7 23:11:25 PST 2013
On 8.11.2013 01:55, David Holmes wrote:
> On 8/11/2013 12:01 AM, Jaroslav Bachorik wrote:
>> Please, review this test fix.
>> Issue : https://bugs.openjdk.java.net/browse/JDK-8004126
>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004126/webrev.00
>> The failure was caused by the IOHandler not waiting for the actual
>> message stating the the debugee was ready.
> So the base problem was that the initial in.read(b, 0, 100) might not
> actually read the message that the debuggee was ready?
It would read the message. But the synchronization could get confused by
an extraneous output before the "ready" message. This is only my best
guess because I was not able to reproduce the error. But looking at the
test this is the only path that could lead to SocketException short of
the debugee application being killed immediately after it has been started.
> The cleanup seems good to me in general. Only concern I have is that
> where the IOHandler would print what was read (which might not be what
> was expected), in the new code if we don't see what we expect we just
> set a boolean to false and the actual output from the debugee is never
> shown - or is the debuggee output captured elsewhere?
ProcessTools.startProcess() takes care of forwarding the stderr and
stdout from the external process to the stderr and stdout of the
launching app. It also adds a disambiguation prefix to the forwarded logs.
> The patch uses the library
>> functions to start the debugee and wait for the actual message to
>> appear. Also, it detects problems while starting the debugee and reports
>> them instead of failing only when the debugger can not connect.
More information about the serviceability-dev