[MERGE] Re: Bug in the new progress bar

[Martin Pool]

2009/1/17 John Arbash Meinel <john at arbash-meinel.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Vincent Ladeuil wrote:
>>>>>>> "jam" == John Arbash Meinel <john at arbash-meinel.com> writes:
>>
>> <snip/>
>>
>>     jam> Note there are still some other oddities.
>>
>> I'm pretty sure Martin implementation reveals latent bugs, I
>> remember having observed strange behavior when doing some 'bzr
>> checks' that were taking days.
>>
>> I view Martin patch as a significant step forward but I think we
>> will discover a couple (or two) of bugs during the 1.12 cycle.

I'll try to push it a bit further through in this cycle - at the
moment you'll only see structural changes and some sftp io reported
this way.

That fix looked good to me.

>>
>> In the meantime:
>>
>> BB:approve
>>
>>         Vincent
>>
>
> For some reason, with this fix, PQM always fails with:
>
>> ======================================================================
>> FAIL: test_shelve_one (bzrlib.tests.blackbox.test_shelve.TestShelveList)
>>
>> vvvv[log from bzrlib.tests.blackbox.test_shelve.TestShelveList.test_shelve_one]
>> 95.294  creating repository in file:///tmp/testbzr-3sBoX0.tmp/bzrlib.tests.blackbox.test_shelve.TestShelveList.test_shelve_one/work/.bzr/.
>> 95.297  creating branch <bzrlib.branch.BzrBranchFormat6 object at 0x2aaaaab2d250> in file:///tmp/testbzr-3sBoX0.tmp/bzrlib.tests.blackbox.test_shelve.TestShelveList.test_shelve_one/work/.bzr/
>> 95.304  trying to create missing lock '/tmp/testbzr-3sBoX0.tmp/bzrlib.tests.blackbox.test_shelve.TestShelveList.test_shelve_one/work/.bzr/checkout/dirstate'
>> 95.304  opening working tree '/tmp/testbzr-3sBoX0.tmp/bzrlib.tests.blackbox.test_shelve.TestShelveList.test_shelve_one/work'
>> 95.314  run bzr: ['shelve', '--list']
>> 95.314  bzr arguments: ['shelve', '--list']
>> 95.315  encoding stdout as sys.stdout encoding 'ANSI_X3.4-1968'
>> 95.317  opening working tree '/tmp/testbzr-3sBoX0.tmp/bzrlib.tests.blackbox.test_shelve.TestShelveList.test_shelve_one/work'
>> 95.323  output:
>> '  1: Foo\n'
>> 95.323  errors:
>> 'Exception exceptions.UserWarning: <exceptions.UserWarning instance at 0x2b7771995050> in <bound method LockableFiles.__del__ of LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///tmp/testbzr-3sBoX0.tmp/bzrlib.tests.blackbox.test_shelve.TestShelveList.test_shelf_order/work/.bzr/repository/>)> ignored\nException exceptions.UserWarning: <exceptions.UserWarning instance at 0x2aaaaac7b998> in <bound method LockableFiles.__del__ of LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///tmp/testbzr-3sBoX0.tmp/bzrlib.tests.blackbox.test_shelve.TestShelveList.test_shelve_no_message/work/.bzr/repository/>)> ignored\n'
>> 95.327  opening working tree '/tmp/testbzr-3sBoX0.tmp'
>>
>> ^^^^[log from bzrlib.tests.blackbox.test_shelve.TestShelveList.test_shelve_one]
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>   File "/home/pqm/bzr-pqm-workdir/home/+trunk/bzrlib/tests/blackbox/test_shelve.py", line 34, in test_shelve_one
>>     self.assertEqual('', err)
>> AssertionError: not equal:
>> a = ''
>> b = 'Exception exceptions.UserWarning: <exceptions.UserWarning instance at 0x2b7771995050> in <bound method LockableFiles.__del__ of LockableFiles(<bzrlib.transptests failed
>> bzrlib.tests.blackbox.test_branch.TestBranchStacked.test_branch_stacked_from_smart_server is leaking threads among 21 leaking tests
>> ort.local.LocalTransport url=file:///tmp/testbzr-3sBoX0.tmp/bzrlib.tests.blackbox.test_shelve.TestShelveList.test_shelf_order/work/.bzr/repository/>)> ignored\nException exceptions.UserWarning: <exceptions.UserWarning instance at 0x2aaaaac7b998> in <bound method LockableFiles.__del__ of LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///tmp/testbzr-3sBoX0.tmp/bzrlib.tests.blackbox.test_shelve.TestShelveList.test_shelve_no_message/work/.bzr/repository/>)> ignored\n'
>
>
> What is even weirder is that test passes when I run it locally. I can't
> test it very thoroughly, because "shelve" doesn't work on Windows, but
> at least that test (when run in isolation) passes.
>
> I certainly feel like this is a 'latent' error, something probably has
> an extra Lock held from another test run, and the garbage collector
> decides to run during this test, and causes an exception that we
> wouldn't otherwise see.
>
> Certainly you can see the lock is held in the "test_shelve_no_message"
> test, even though it is causing the "test_shelve_one" test to fail.
>
> Anyway, I'll try to get back to this on Tuesday (Monday, Jan 19th is a
> holiday in the US). If anyone else gets to it, more power to you.

This might be something to do with Warnings being printed only once
(in some modes?) - if that line is hit earlier on, before we have
stderr captured, and something may have changed that means it's now
not seen until this point.

If I were getting that error I'd probably set -Werror and try to work
out what's actually raising it.  (Modulo the problem of testing it on
Windows...)

If we don't want to do that, or aren't getting around to squashing
them, it reinforces my opinion that these shouldn't really be
warnings.

-- 
Martin <http://launchpad.net/~mbp/>