Tcl Source Code

Ubuntu based OS, 32 bit, kernel 2.6.35-30, ActiveState 8.6b2 binary. 

Starting with the latest beta, my "socket -server" code stopped working in my code. It appears that setting the server socket encoding to any value, ie "-encoding binary" or even to the value it is currently set to stops the server from responding. 

Initially I thought it was the -blocking setting since it was the only setting I was changing from it's default value but after I started experimenting with the settings by  changing each one individually, the culprit turned out to be -encoding.

Committed now. Sorry for the delay.

Reinhard, what's the status ? I was under the impression that you had this all done in your sandbox...

File Added - 421629: servconfig.patch

I'm all for minimal changes. If we feel later that the current sequence should be revised, that can be done in a separate patch (still your multiple-address patch doesn't really need it).
The attached patch does this, by restoring the test as you suggested, but also keeping the comment explaining the assumptions. This way a future reform won't miss it.

Ah - I recently removed the check for server sockets from TcpWatchProc() after I didn't find a way for it to ever get called for server sockets. But as a result of [chan configure -encoding] it does get called and removes the FileHandler for the first file descriptor in the socket. It is only the first, because connected sockets for which TcpWatchProc() is normally called, only ever have one fd and so it doesn't need to loop over them.

I could re-add the check to skip server sockets, but suggest to further investigate if changing the encoding really needs to call the watchproc. Also, it might be cleaner to not specify a watchproc in the Tcl_ChannelType struct for server sockets at all, so that TcpWatchProc() doesn't need to check for them. This would mean that separate Tcl_ChannelType structs would have to be maintained for client and server sockets, which might not be so bad, because there are more members in the struct that don't make much sense for server socckets.

In any case, we should add a test case for this, so that it can't re-appear.

As a quick fix the following line can be added at the start of TcpWatchProc():
if (statePtr->acceptProc != NULL) return;

Some strace debugging revealed that after fconfigure -encoding, the first (or the only in case there is just one) file descriptor that underlays a [socket -server] gets skipped from the select() call that results from [update] or [vwait]. If there is more than one actual socket under the hood of the server channel (e.g. when the socket listens on both, IPv4 and IPv6), the second socket in the list (the IPv6 one in my case) still works after the [fconfigure].

I've attached the contents of the paste as a file so that they don't get lost in the future.

File Added - 421593: socketbug.txt

The previous pastebin expires in one day. This is a copy of it that does not expire, in case someone needss to see it:

http://pastebin.com/2xmykvVt

Strongly suspect the IPv6 changes.

I confirm reproduction of the pastebin
symptoms on the trunk tip.

http://pastebin.com/3mT6KPG6

[11:54]akuThe only big change I recall to 'socket -server' is IPv6 support getting added.
[11:54]akuAre you setting the encoding of the listening socket ? Or of the socket you get when the connection is accepted ?