From: <no...@so...> - 2002-07-06 17:59:24
|
Bugs item #578164, was opened at 2002-07-06 13:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=578164&group_id=10894 Category: 26. Channel Types Group: 8.4b1 Status: Open Resolution: None Priority: 5 Submitted By: Kevin B KENNY (kennykb) Assigned to: Andreas Kupries (andreas_kupries) Summary: socket-2.4 fails on WinNT Initial Comment: In the current HEAD, socket-2.4 appears not to be working owing to some sort of synchronization problem within the test case. ==== socket-2.4 tcp connection with server interface specified FAILED ==== Contents of test case: removeFile script set f [open $path(script) w] puts $f { set timer [after 2000 "set x done"] set f [socket -server accept -myaddr [info hostname] 0] proc accept {file addr port} { global x puts "[gets $file]" close $file set x done } puts ready puts [lindex [fconfigure $f -sockname] 2] vwait x after cancel $timer close $f } close $f set f [open "|[list $::tcltest::tcltest $path(script)]" r] gets $f x gets $f listen if {[catch {socket [info hostname] $listen} sock]} { set x $sock } else { puts $sock hello flush $sock lappend x [gets $f] close $sock } close $f set x ---- Result was: couldn't open socket: connection refused ---- Result should have been (exact matching): ready hello ==== socket-2.4 FAILED ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=578164&group_id=10894 |
From: <no...@so...> - 2002-07-08 21:38:17
|
Bugs item #578164, was opened at 2002-07-06 10:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=578164&group_id=10894 Category: 26. Channel Types Group: 8.4b1 Status: Open Resolution: None Priority: 5 Submitted By: Kevin B KENNY (kennykb) Assigned to: Andreas Kupries (andreas_kupries) Summary: socket-2.4 fails on WinNT Initial Comment: In the current HEAD, socket-2.4 appears not to be working owing to some sort of synchronization problem within the test case. ==== socket-2.4 tcp connection with server interface specified FAILED ==== Contents of test case: removeFile script set f [open $path(script) w] puts $f { set timer [after 2000 "set x done"] set f [socket -server accept -myaddr [info hostname] 0] proc accept {file addr port} { global x puts "[gets $file]" close $file set x done } puts ready puts [lindex [fconfigure $f -sockname] 2] vwait x after cancel $timer close $f } close $f set f [open "|[list $::tcltest::tcltest $path(script)]" r] gets $f x gets $f listen if {[catch {socket [info hostname] $listen} sock]} { set x $sock } else { puts $sock hello flush $sock lappend x [gets $f] close $sock } close $f set x ---- Result was: couldn't open socket: connection refused ---- Result should have been (exact matching): ready hello ==== socket-2.4 FAILED ---------------------------------------------------------------------- >Comment By: Andreas Kupries (andreas_kupries) Date: 2002-07-08 14:38 Message: Logged In: YES user_id=75003 Sorry, I am unable to reproduce this on my Win2K system. Does this happen for every run, or only now and then ? How many server sockets are open on your system ? Maybe you exceeded what the system allows. The only possible sync problem which might exist is the race between reading the port number from the pipe and opening the socket in the caller, and writing the port number and entering the event loop in the server. I am unsure about this because the server socket already does exist at that time and maybe the OS buffers a connection request coming in, before the event loop starts looking for such events. And this we should be able to avoid with a small delay between 'gets $f listen' and the 'socket' command. [after 1000] or so. Can you test this ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=578164&group_id=10894 |
From: <no...@so...> - 2002-07-08 21:44:46
|
Bugs item #578164, was opened at 2002-07-06 13:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=578164&group_id=10894 Category: 26. Channel Types Group: 8.4b1 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Kevin B KENNY (kennykb) Assigned to: Andreas Kupries (andreas_kupries) Summary: socket-2.4 fails on WinNT Initial Comment: In the current HEAD, socket-2.4 appears not to be working owing to some sort of synchronization problem within the test case. ==== socket-2.4 tcp connection with server interface specified FAILED ==== Contents of test case: removeFile script set f [open $path(script) w] puts $f { set timer [after 2000 "set x done"] set f [socket -server accept -myaddr [info hostname] 0] proc accept {file addr port} { global x puts "[gets $file]" close $file set x done } puts ready puts [lindex [fconfigure $f -sockname] 2] vwait x after cancel $timer close $f } close $f set f [open "|[list $::tcltest::tcltest $path(script)]" r] gets $f x gets $f listen if {[catch {socket [info hostname] $listen} sock]} { set x $sock } else { puts $sock hello flush $sock lappend x [gets $f] close $sock } close $f set x ---- Result was: couldn't open socket: connection refused ---- Result should have been (exact matching): ready hello ==== socket-2.4 FAILED ---------------------------------------------------------------------- >Comment By: Kevin B KENNY (kennykb) Date: 2002-07-08 17:44 Message: Logged In: YES user_id=99768 Sorry about the false alarm. There was a brief DNS outage while I was running the test suite, and that apparently caused the problem. We might want to have the tests use 127.0.0.1 in place of [info hostname] when making connections that are known to be on the local host. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2002-07-08 17:38 Message: Logged In: YES user_id=75003 Sorry, I am unable to reproduce this on my Win2K system. Does this happen for every run, or only now and then ? How many server sockets are open on your system ? Maybe you exceeded what the system allows. The only possible sync problem which might exist is the race between reading the port number from the pipe and opening the socket in the caller, and writing the port number and entering the event loop in the server. I am unsure about this because the server socket already does exist at that time and maybe the OS buffers a connection request coming in, before the event loop starts looking for such events. And this we should be able to avoid with a small delay between 'gets $f listen' and the 'socket' command. [after 1000] or so. Can you test this ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=578164&group_id=10894 |
From: <no...@so...> - 2002-07-08 21:54:13
|
Bugs item #578164, was opened at 2002-07-06 10:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=578164&group_id=10894 Category: 26. Channel Types Group: 8.4b1 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Kevin B KENNY (kennykb) Assigned to: Andreas Kupries (andreas_kupries) Summary: socket-2.4 fails on WinNT Initial Comment: In the current HEAD, socket-2.4 appears not to be working owing to some sort of synchronization problem within the test case. ==== socket-2.4 tcp connection with server interface specified FAILED ==== Contents of test case: removeFile script set f [open $path(script) w] puts $f { set timer [after 2000 "set x done"] set f [socket -server accept -myaddr [info hostname] 0] proc accept {file addr port} { global x puts "[gets $file]" close $file set x done } puts ready puts [lindex [fconfigure $f -sockname] 2] vwait x after cancel $timer close $f } close $f set f [open "|[list $::tcltest::tcltest $path(script)]" r] gets $f x gets $f listen if {[catch {socket [info hostname] $listen} sock]} { set x $sock } else { puts $sock hello flush $sock lappend x [gets $f] close $sock } close $f set x ---- Result was: couldn't open socket: connection refused ---- Result should have been (exact matching): ready hello ==== socket-2.4 FAILED ---------------------------------------------------------------------- >Comment By: Jeffrey Hobbs (hobbs) Date: 2002-07-08 14:54 Message: Logged In: YES user_id=72656 It is important to note that [info hostname] will of course follow different code paths, so it may not be appropriate to replace it for all tests. Also, at the OS leve, the loopback address often follows a different codepath than referring to machine by name or global IP. This may not be important to all tests, but there are likely a few where info hostname should still be used. ---------------------------------------------------------------------- Comment By: Kevin B KENNY (kennykb) Date: 2002-07-08 14:44 Message: Logged In: YES user_id=99768 Sorry about the false alarm. There was a brief DNS outage while I was running the test suite, and that apparently caused the problem. We might want to have the tests use 127.0.0.1 in place of [info hostname] when making connections that are known to be on the local host. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2002-07-08 14:38 Message: Logged In: YES user_id=75003 Sorry, I am unable to reproduce this on my Win2K system. Does this happen for every run, or only now and then ? How many server sockets are open on your system ? Maybe you exceeded what the system allows. The only possible sync problem which might exist is the race between reading the port number from the pipe and opening the socket in the caller, and writing the port number and entering the event loop in the server. I am unsure about this because the server socket already does exist at that time and maybe the OS buffers a connection request coming in, before the event loop starts looking for such events. And this we should be able to avoid with a small delay between 'gets $f listen' and the 'socket' command. [after 1000] or so. Can you test this ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=578164&group_id=10894 |
From: <no...@so...> - 2002-07-08 21:58:20
|
Bugs item #578164, was opened at 2002-07-06 10:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=578164&group_id=10894 Category: 26. Channel Types Group: 8.4b1 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Kevin B KENNY (kennykb) Assigned to: Andreas Kupries (andreas_kupries) Summary: socket-2.4 fails on WinNT Initial Comment: In the current HEAD, socket-2.4 appears not to be working owing to some sort of synchronization problem within the test case. ==== socket-2.4 tcp connection with server interface specified FAILED ==== Contents of test case: removeFile script set f [open $path(script) w] puts $f { set timer [after 2000 "set x done"] set f [socket -server accept -myaddr [info hostname] 0] proc accept {file addr port} { global x puts "[gets $file]" close $file set x done } puts ready puts [lindex [fconfigure $f -sockname] 2] vwait x after cancel $timer close $f } close $f set f [open "|[list $::tcltest::tcltest $path(script)]" r] gets $f x gets $f listen if {[catch {socket [info hostname] $listen} sock]} { set x $sock } else { puts $sock hello flush $sock lappend x [gets $f] close $sock } close $f set x ---- Result was: couldn't open socket: connection refused ---- Result should have been (exact matching): ready hello ==== socket-2.4 FAILED ---------------------------------------------------------------------- >Comment By: Andreas Kupries (andreas_kupries) Date: 2002-07-08 14:58 Message: Logged In: YES user_id=75003 From the comments below and talking with Jeff I have decided to make the change for the test mentioned in this report, i.e. socket-2.4, but nowhere else. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2002-07-08 14:54 Message: Logged In: YES user_id=72656 It is important to note that [info hostname] will of course follow different code paths, so it may not be appropriate to replace it for all tests. Also, at the OS leve, the loopback address often follows a different codepath than referring to machine by name or global IP. This may not be important to all tests, but there are likely a few where info hostname should still be used. ---------------------------------------------------------------------- Comment By: Kevin B KENNY (kennykb) Date: 2002-07-08 14:44 Message: Logged In: YES user_id=99768 Sorry about the false alarm. There was a brief DNS outage while I was running the test suite, and that apparently caused the problem. We might want to have the tests use 127.0.0.1 in place of [info hostname] when making connections that are known to be on the local host. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2002-07-08 14:38 Message: Logged In: YES user_id=75003 Sorry, I am unable to reproduce this on my Win2K system. Does this happen for every run, or only now and then ? How many server sockets are open on your system ? Maybe you exceeded what the system allows. The only possible sync problem which might exist is the race between reading the port number from the pipe and opening the socket in the caller, and writing the port number and entering the event loop in the server. I am unsure about this because the server socket already does exist at that time and maybe the OS buffers a connection request coming in, before the event loop starts looking for such events. And this we should be able to avoid with a small delay between 'gets $f listen' and the 'socket' command. [after 1000] or so. Can you test this ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=578164&group_id=10894 |