selftest results for lp:bzr revno.4804

[Vincent Ladeuil]

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

<snip/>

    jam> We have a bit of kipple from:
    jam> Exception RuntimeError: 'maximum recursion depth exceeded in
    jam> __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored

That one is present almost everywhere.

<snip/>

    jam> Seemed to fix them for me, but that is a kludgey
    jam> workaround. I think the issue is that we aren't
    jam> synchronously closing the file stream over sftp (instead
    jam> doing it asynchronously). And on a single CPU machine,
    jam> the sftp thread never gets control to actually run
    jam> 'close'. Hence why 'time.sleep(0.001)' is enough to make
    jam> it work.

That sounds exactly like the sync bugs I'm fixing to avoid leaks,
sleeping is another way to transfer control to the other thread
when the threads aren't synchronized. It may still fail but more
rarely.

    jam> I should note for Vincent that I never run with
    jam> --parallel.

Hmm, well, that means the sync bugs manifest themselves
differently on windows and the leaks have different consequences.

By the way, how many leaking tests are reported ?

    jam> I *do* tend to run with --subunit, but it isn't required
    jam> for the test suite to pass.

Good, a different result would have been annoying.

      Vincent