On Tue, 23 Jan 2007, Rick Jones wrote: > Herbert Xu wrote: > > Prior to the last write, the socket entered the CLOSED state meaning > > that the old port is no longer allocated to it. As a result, the > > last write operates on an unconnected socket which causes a new local > > port to be allocated as an autobind. It then fails because the socket > > is still not connected. > > > > So any attempt to run getsockname after an error on the socket is > > simply buggy. > > But falls within the principle of least surprise doesn't it? Unless the > application has called close() or bind(), it does seem like a reasonable > expectation that the port assignments are not changed.
i sampled a few other OSes... netbsd returns EINVAL after close freebsd returns ECONNRESET after close OSX retains the same port number solaris 10 returns port 0 actually any of those behaviours seems more appropriate than randomly assigning a new port :) but i like the ENOTCONN suggestion from Michael Tokarev the best... it matches the ENOTCONN from getpeername. > > (fwiw this is one of two reasons i've found for libnss-ldap to leak > > sockets... causing nscd to crash.) > > Of course, that seems rather odd too - why does libnss-ldap check the socket > name on a socket after an EPIPE anyway? libnss-ldap has some code which attempts to determine if its private socket has been trampled on in between calls to the library... and to do this it caches getsockname/getpeername results and compares them every time the library is re-entered... and when there's a mismatch it leaks a socket (eventually crashing nscd if you're using that). i've been trying to band-aid over the problem: http://bugzilla.padl.com/show_bug.cgi?id=304 http://bugzilla.padl.com/show_bug.cgi?id=305 but i'm probably going to need to approach it from another direction -- make libnss-ldap monitor the ldap library results so it knows when there's been a read/write error so that it stops doing this getsockname/getpeername thing after the error has occured. -dean - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
