TCP reset caused by socket.py

[Gabriel Genellina]

En Tue, 11 Dec 2007 10:51:13 -0300, Object01 <object01 at gmail.com> escribi�:

> I've been working with the source code for Trac (http://
> trac.edgewall.org/) lately and have run across a bizarre problem.  It
> seems that all POST requests to Trac's standalone server (tracd) have
> a random chance of causing the server to issue a TCP RST packet that
> resets the connection.
>
> Running Trac 10.3.1 on Win2K3 using Python 2.4, watching traffic with
> Wireshark 0.99.5.
>
> I've been stepping through the code using Winpdb 1.3.2 and have
> isolated the problem to the socket.py that's included in Python 2.4.
> Line 157, in _socketobject.close():
>
>   self.send = self.recv = self.sendto = self.recvfrom =
> self._sock._dummy
>
> is what's causing the TCP RST to be issued.  If I set a breakpoint on
> that line and step over it on a POST request, there's about an 80%
> chance the server will issue a TCP RST.  When debugging, the entire
> response makes it onto the wire before TCP RST is issued.  If I'm -
> not- debugging, it's anybody's guess as to how much of the response
> makes it out. The interruption, when it occurs, always seems to be
> between calls to _fileobject.write().  This indicates a timing issue:
> perhaps buffered data isn't being waited on properly prior to
> the .close() method doing its work.

I think the trigger is the line just above that, where the "real" socket  
is deleted. A RST when you close a socket is OK. From your description it  
appears that the close method should not have been called at that time;  
I'd look at the stack and see why is it being called when it shouldn't.

I don't believe Python itself randomly calls close() so it looks like a  
Trac problem, or in the webserver used. Is there any timer used? Is the  
server multithreaded?

-- 
Gabriel Genellina