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.
-JB-
Thanks,
David
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.
Thanks,
-JB-
