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.

[Bjoern Schliessmann]

Gabriel Genellina wrote:

A RST when you close a socket is OK.

Says who? MS? ;)

Regards,
Björn

--
BOFH excuse #328:

Fiber optics caused gas main leak

[Gabriel Genellina]

En Wed, 12 Dec 2007 15:46:14 -0300, Bjoern Schliessmann
<us**************************@spamgourmet.comescri bió:

Gabriel Genellina wrote:

>A RST when you close a socket is OK.

Says who? MS? ;)

Nevermind... just nonsense!

--
Gabriel Genellina

[Object01]

Is this applicable in your case?:http://brad.livejournal.com/2152593....2273#t10832273

(closing a nonblocking socket with a nonempty output queue generates a RST)

Based on my stepping through the code, everything passed to
_fileobject.write() makes it out onto the wire just fine. Now, if the
debugger isn't attached, like I said, it's anybody's guess how much
data gets out before the RST shows up. I need to delve deeper into
Trac's use of blocking vs. non-blocking sockets.

Indirectly: if the _sock attribute was the last reference to the real
socket object (and that's likely the case), assigning anything to _sock
will decrement its reference count to 0, then becoming a candidate for
garbage collection.

--
Gabriel Genellina

I don't know much about the timing of Python's garbage collection. Is
it pretty aggressive?

--
Jeff S.

[Bjoern Schliessmann]

Object01 wrote:

Is there something I can look for in the packet traffic that would
indicate one party is misbehaving? The sequence numbers seem ok.
*shrug* I'd expect to see data sent from server to client and
then see a sequence of packets that close the connection
gracefully. Instead I see the server send data to the client and
then a RST, nothing more.

I'm not sure, without any context. RSTs also seem to be used if a
TCP port is "closed", though from your description it seems that a
connection has been established when those RSTs come in.

Regards,
Björn

--
BOFH excuse #249:

Unfortunately we have run out of bits/bytes/whatever. Don't worry,
the next supply will be coming next week.

[Gabriel Genellina]

En Wed, 12 Dec 2007 20:12:43 -0300, Object01 <ob******@gmail.comescribi�:

I don't know much about the timing of Python's garbage collection. Is
it pretty aggressive?

As soon as the reference count reaches zero (at least for current CPython
version). Objects that are part of a reference cycle may take a while but
are detected and collected eventually.

--
Gabriel Genellina