TCP reset caused by socket.py

[Object01]

On Dec 11, 6:17 pm, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
wrote:
> En Tue, 11 Dec 2007 10:51:13 -0300, Object01 <objec... 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

The server is multithreaded, handling each request on its own thread.
But is a RST really a part of a valid close operation?  It was my
understanding that the RST is used to indicate a problem with the
connection, usually a half-open connection.  I never see RSTs unless
this error occurs.

Looking at the stack, it appears the socket is being closed at the
right time.  All data has been sent and the request handler is in its
tear-down phase, expecting no more data from the client (who never
sends any).  I don't see different stack traces between error and no-
error requests.

And on line 156, how is the real socket being deleted?  It (the _sock
member) appears to be set to a dummy class that has no real
functionality.

--
Jeff S.