On Fri, 27 Jun 2008, Robert Watson wrote:
I've asked Ali to do a bit more debugging and tracing of the application to see if we can reach any conclusions about this. In particular, if he traces to a file all file descriptor numbers returned by accept(2), then we can later compare that file with the leaked descriptors present in netstat/sockstat and decide whether the application *should* have known they were open or not.
Another public follow-up: Ali has been sending me debugging information privately due to the inclusion of application source code and IP addresses. Tracing of the application suggests that there is an application concurrency bug leading to one socket to be closed twice and another socket to be left open. The bug might be triggering in 7.x but not earlier releases because of the change to libthr, which can lead to more parallelism/asynchrony in the application.
In conclusion: we currently believe that this report of sockets stuck in the CLOSED state is not the result of a kernel bug. If any further information comes to light, I will send a followup.
Thanks, Robert N M Watson Computer Laboratory University of Cambridge _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
