On Tue, 23 Jan 2007, David Miller wrote: > From: dean gaudet <[EMAIL PROTECTED]> > Date: Tue, 23 Jan 2007 12:11:01 -0800 (PST) > > > 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. > > Please do not write programs in this way. getsockname/getpeername > were never meant to be used in that way, and it's hella inefficient > to keep checking the socket like that to boot. > > I really don't see you gaining anything by making this check every > time the user calls into the library. > > If the application mucks with the communications channel socket, so > what, it's his application that will go tits up. > > Is there some tricky interaction between nscd and something like > libnss-ldap that makes this tom-foolery necessary? >
oh heck yeah i totally agree -- it's not my code though, i'm just debugging it. -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
