TCP reset caused by socket.py

[Gabriel Genellina]

En Wed, 12 Dec 2007 13:38:21 -0300, Object01 <object01 at gmail.com> escribió:

> 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.

> The server is multithreaded, handling each request on its own thread.
> But is a RST really a part of a valid close operation?

No! Sorry, just nonsense.

> 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.

Is this applicable in your case?:
http://brad.livejournal.com/2152593.html?thread=10832273#t10832273
(closing a nonblocking socket with a nonempty output queue generates a RST)

> 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.

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