[Merge] lp:~vila/bzr/leaking-tests into lp:bzr

[Vincent Ladeuil]

>>>>> John Arbash Meinel <john at arbash-meinel.com> writes:

<snip/>

    > So I've think I've managed to track down the issue to a _probe_bzrdir
    > call that doesn't seem to be cleaning up its connection. See the
    > attached error messages.

Excellent, I don't why I don't get any of this backtraces on XP, but
I'm pretty sure I understand what is happening there.

    > Basically, I wrapped socket.socket() to produce an object that
    > tracks the traceback when it was created, and then caches that
    > when .connect() is called. 

Interesting, care to show us how you achieve that ? That would certainly
help a lot.

    > And then when I later get a failure at shutdown, I check who the
    > peer was, and print its traceback. I'm pretty sure that is
    > correct, though I don't entirely know why my other code doesn't
    > find it correctly.

    > My guess is the socket is trapped because of something like we "raise
    > NotBranchError" and that leaves the socket in some sort of gc cycle.

So, I think it's one of these "valid" hangs: the connection thread is in
a blocking read but the client will never write because it has nothing
more to ask.

    > John
    > =:->
    > c:\Python26\lib\site-packages\pycrypto-2.0.1-py2.6-win32.egg\Crypto\Hash\SHA.py:6: DeprecationWarning: the sha module is deprecated; use the hashlib module instead
    >   from sha import *
    > c:\Python26\lib\site-packages\pycrypto-2.0.1-py2.6-win32.egg\Crypto\Hash\MD5.py:6: DeprecationWarning: the md5 module is deprecated; use hashlib instead
    >   from md5 import *
    > _ensure_connection connected as ('127.0.0.1', 52372) peer ('127.0.0.1', 52371)
    > sent request for mkdir on ('127.0.0.1', 52372) peer: ('127.0.0.1', 52371)
    > sent request for BzrDirFormat.initialize on ('127.0.0.1', 52372) peer: ('127.0.0.1', 52371)
    > sent request for BzrDir.open_2.1 on ('127.0.0.1', 52372) peer: ('127.0.0.1', 52371)
    > sent request for BzrDir.create_repository on ('127.0.0.1', 52372) peer: ('127.0.0.1', 52371)
    > sent request for BzrDir.create_branch on ('127.0.0.1', 52372) peer: ('127.0.0.1', 52371)
    > stopping the background thread by doing a no-op connection
    > no-op connection connected @ ('127.0.0.1', 52378), closing

-Ethreads should gives you part of that (but not the association between
 socket.socket() and .close).

The difference here between linux and windows seems to be that the
connection thread doesn't realize that the client has shutdown()/close()
the socket and that's where killing the thread may be the only viable
solution.

It's the same scenario than for connection threads for http/1.1: the
server is required to keep the connection opened which requires the
client to close the socket, but this close doesn't seem to be propagated
cleanly.

Alternatively we may try to write a random byte from the client...

              Vincent