From: SourceForge.net <no...@so...> - 2011-06-25 22:04:57
|
Bugs item #3325339, was opened at 2011-06-23 22:19 Message generated for change (Comment added) made by ferrieux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3325339&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 27. Channel Types Group: development: 8.6b1.1 Status: Open Resolution: None Priority: 9 Private: No Submitted By: Don Porter (dgp) Assigned to: Reinhard Max (rmax) Summary: socket-14.2 fails Initial Comment: I think this failure comes from the merge of the rmax-ipv6-branch to trunk. ==== socket-14.2 [socket -async] fileevent connection refused FAILED ==== Contents of test case: set client [socket -async localhost [randport]] fileevent $client writable {set x [fconfigure $client -error]} set after [after 1000 {set x timeout}] vwait x if {$x eq "timeout"} { append x ": [fconfigure $client -error]" } set x ---- Result was: timeout: connection refused ---- Result should have been (exact matching): connection refused ==== socket-14.2 FAILED ---------------------------------------------------------------------- >Comment By: Alexandre Ferrieux (ferrieux) Date: 2011-06-26 00:04 Message: Oh, my conclusion from strace was hasty: the fileevent doesn't fire. Here, source-diving is much more productive. The core of the bug is that with the new code, an internal writable fileevent is set up (TcpAsyncCallback), and when this one is called, it does Tcl_DeleteFileHandler(), which wipes out any user-provided fileevents. Clearly this is new and related to the new callback, made necessary for multiple-address iterations. I'll dive a bit more to grok how one is supposed to remove fileevents one by one. Just specifying the fd sounds too coarse. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2011-06-25 19:12 Message: FWIW, I do reproduce in 8.6, threaded and unthreaded, on my Fedora 12, but not in 8.5, threaded or unthreaded. Also, a bit of strace shows that in the failing case, the fileevent does fire, but doesn't unlock th e vwait. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2011-06-24 23:02 Message: Reinhard, can you provide an strace -f -tt -T of the failing 8.5 and 8.6 on your machine ? ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2011-06-24 20:03 Message: CentOS release 5.6 (Final) $ uname -a Linux localhost.localdomain 2.6.18-238.12.1.el5 #1 SMP Tue May 31 13:23:01 EDT 2011 i686 i686 i386 GNU/Linux ---------------------------------------------------------------------- Comment By: Reinhard Max (rmax) Date: 2011-06-23 23:11 Message: On what OS does socket-14.2 fail? The http-4.14 failure is almost certainly unrelated to the ipv6 merge, because it also fails for me on 8.5. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2011-06-23 22:30 Message: Also failing: ==== http-4.14 http::Event FAILED ==== Contents of test case: set token [http::geturl $badurl/?timeout=10 -timeout 10000 -command \#] if {$token eq ""} { error "bogus return from http::geturl" } http::wait $token http::status $token # error code varies among platforms. ---- Test completed normally; Return code was: 0 ---- Return code should have been one of: 1 ==== http-4.14 FAILED ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3325339&group_id=10894 |