Re: RFR: JDK-8013728: nsk/jdi/BScenarios/hotswap/tc10x001 Unrecognized Windows Sockets error: 0: recv failed
+1 --alex On 03/08/2019 08:58, Chris Plummer wrote: Looks good. Chris On 3/8/19 5:16 AM, Gary Adams wrote: I've been able to reproduce the socket teardown failure in tc10x001. It appears that the debugee sends it's final output and then exits. If the debugee exits while the debugger is receiving the final output, it can result in a socket error. This proposed fix forces the debugee to wait until the debugger acknowledges it has processed the final output before exitting. Webrev: http://cr.openjdk.java.net/~gadams/8013728/webrev.01/ The original bug was filed before these tests were in the open repos. None of the other tests in the nsk/jdi/BScenarios set have shown this problem, because they do not have an early debuggee exit sequence.
Re: RFR: JDK-8013728: nsk/jdi/BScenarios/hotswap/tc10x001 Unrecognized Windows Sockets error: 0: recv failed
Looks good. Chris On 3/8/19 5:16 AM, Gary Adams wrote: I've been able to reproduce the socket teardown failure in tc10x001. It appears that the debugee sends it's final output and then exits. If the debugee exits while the debugger is receiving the final output, it can result in a socket error. This proposed fix forces the debugee to wait until the debugger acknowledges it has processed the final output before exitting. Webrev: http://cr.openjdk.java.net/~gadams/8013728/webrev.01/ The original bug was filed before these tests were in the open repos. None of the other tests in the nsk/jdi/BScenarios set have shown this problem, because they do not have an early debuggee exit sequence.
RFR: JDK-8013728: nsk/jdi/BScenarios/hotswap/tc10x001 Unrecognized Windows Sockets error: 0: recv failed
I've been able to reproduce the socket teardown failure in tc10x001. It appears that the debugee sends it's final output and then exits. If the debugee exits while the debugger is receiving the final output, it can result in a socket error. This proposed fix forces the debugee to wait until the debugger acknowledges it has processed the final output before exitting. Webrev: http://cr.openjdk.java.net/~gadams/8013728/webrev.01/ The original bug was filed before these tests were in the open repos. None of the other tests in the nsk/jdi/BScenarios set have shown this problem, because they do not have an early debuggee exit sequence.
