TCP reset caused by socket.py

[Object01]

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 can't tell if this is a problem with the way Trac was coded (i.e.
are they violating the rules of sockets?) or whether it indicates a
problem in Python's socket implementation.  Either way, isn't this a
strange statement (an assignment) for a TCP RST to occur?  I can only
figure that the garbage collector is unpredictably disposing of a
socket at this opportunity.  And why only for POST requests?

I'm looking for any insight anyone can provide about this!

--
Jeff S.