I don't know about the socket leak, per se, but I have had some
dealings with the original BSD network stack with regards to the
accept() call. From my memory, I remember there being two queues on
which the socket might be placed (so_comp, so_incomp). Depending on the
timing, the socket might be on the incomplete or the completed queue
when the RST arrives. Perhaps there is a bug in one of these code paths
when receiving a RST (probably the so_incomp queue).
Jay
On 7/27/2010 3:14 PM, Grant Edwards wrote:
I'm seeing what appears to me to be a socket leak in the accept()
operation provided by the "new" BSD network stack.
One of my customers is doing something goofy (but legal) on his end
which occasionally opens a socket (SYN,SYN/ACK,ACK) and then 140-150
us later sends a TCP RST. This results in accept() on my end returning
-1 with errno set to 353 (ECONNABORTED). Each time this happens it
appears that a socket gets leaked. After about 240 such aborts, the
stack runs out of sockets (I've configured eCos for 256 sockets, and
there are 16 other sockets that are always in-use).
If the TCP connection stays open for even a few milliseconds (long
enoug for accept() to return>= 0), then I never have any problems.
Has anybody seen this issue before?
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
