On Sun, 17 Oct 2004, Vlad wrote: > is there a specific condition when that happens? I tried to simulate > heavy tcp traffic from number of sources but could not induct the panic > by such artificial traffic. It happened to me only in 'natural' way ;) > > so maybe if you know exactly how to trigger it, and share that with us, > we could do some workaround on live production servers so it doesn't > happen, until it's fixed in the code? Yeah -- I'm cleaning up the reproduction pieces and will commit them to the FreeBSD source tree in the regression area this evening or tomorrow. Basically, the race that seems to currently be triggering occurs when there's a simultaneous close() on a socket at the same time as a RST is received on the socket causing the protocol to also try and close the socket. I reproduce it by running the tcpconnect server (in the regression tree) on a TCP port, then running the test tool so that it connects and immediately resets the connection. I.e., it sounds like a reference count issue due to sockets using a slightly aberrant reference model. I'll try to come up with a workaround sometime in the next 12-24 hours, and hopefully also a proper fix. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert_at_fledge.watson.org Principal Research Scientist, McAfee Research > > > > The good news and the bad news: after spending a day or two hacking up an > > IP stack simulator to simulate various nasty combinations of TCP packets, > > I've managed to reproduce the problem, and am able to get a core. I'm > > currently working on tracking down the problem. > > -- > Vlad >Received on Sun Oct 17 2004 - 19:27:30 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:18 UTC