selftest gives warnings about "not explicitly unlocked"

[Matthew Fuller]

selftest gives a few warnings about resources not being explicitly unlocked. vis:

[4314/6486 in 1184s, 2 failed, 244 skipped, 2 missing features] branch_implemen/home/fullermd/src/bzr/conditionalize-format-warning/bzrlib/lockable_files.py:110: UserWarning: file group LockableFiles(<bzrlib.transport.remote.RemoteTransport url=bzr://127.0.0.1:58001/b/.bzr/repository/>) was not explicitly unlocked
  warn("file group %r was not explicitly unlocked" % self)
[4318/6486 in 1184s, 2 failed, 244 skipped, 2 missing features] branch_implemen/home/fullermd/src/bzr/conditionalize-format-warning/bzrlib/lockable_files.py:110: UserWarning: file group LockableFiles(<bzrlib.transport.remote.RemoteTransport url=bzr://127.0.0.1:58013/b/.bzr/repository/>) was not explicitly unlocked
  warn("file group %r was not explicitly unlocked" % self)

[Robert Collins (lifeless)]

if you run with -v and look for this is should be just after the test causing it. If you can narrow down the test(s) doing it that would be freat.

Clearly its a test using 'b' as the path for a repository, if that helps.

It doesn't happen on PQM (because pqm runs with -Werror

[John A Meinel (jameinel)]

I just realized that it could happen on PQM, as long as it is happening in the server-side process. It may cause a traceback in the server, but we could easily be ignoring that locally. There are a few chances for this since sub-processes and threads don't propagate their errors to the test-running thread.

[Bubba Siggler (bud3)]

On 4/24/07, fullermd <email address hidden> wrote:
>
> Public bug reported:
>
> selftest gives a few warnings about resources not being explicitly
> unlocked. vis:

   - Hi, fullermd,
   - I belive you was trying to explain the selftest late noon here. I
   was getting a medusa waring. but thought it was something part of the test
   to over look.
   - you need more selftest run on this end if so is it the ones above.

        bubba

[4314/6486 in 1184s, 2 failed, 244 skipped, 2 missing features]
> branch_implemen/home/fullermd/src/bzr/conditionalize-format-warning/bzrlib/lockable_files.py:110:
> UserWarning: file group LockableFiles(<
> bzrlib.transport.remote.RemoteTransporturl=bzr://127.0.0.1:58001/b/.bzr/repository/>) was not explicitly unlocked
> warn("file group %r was not explicitly unlocked" % self)
> [4318/6486 in 1184s, 2 failed, 244 skipped, 2 missing features]
> branch_implemen/home/fullermd/src/bzr/conditionalize-format-warning/bzrlib/lockable_files.py:110:
> UserWarning: file group LockableFiles(<
> bzrlib.transport.remote.RemoteTransporturl=bzr://127.0.0.1:58013/b/.bzr/repository/>) was not explicitly unlocked
> warn("file group %r was not explicitly unlocked" % self)
>
> ** Affects: bzr (upstream)
> Importance: Undecided
> Status: Unconfirmed
>
> --
> selftest warnings
> https://bugs.launchpad.net/bugs/109520
> You received this bug notification because you are a member of Bazaar
> Developers, which is the registrant for Bazaar.
>

--
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFkcN7yXWcajQQndYRAgbqAKCMyXN9Jx4g0X7jocg+aUSFz0x4LwCgrURW
eGtqLjpzQVYa9+gzpCRtB84=
=zrpM
-----END PGP SIGNATURE-----

[Robert Collins (lifeless)]

On Wed, 2007-04-25 at 18:56 +0000, John A Meinel wrote:
> I just realized that it could happen on PQM, as long as it is happening
> in the server-side process. It may cause a traceback in the server, but
> we could easily be ignoring that locally. There are a few chances for
> this since sub-processes and threads don't propagate their errors to the
> test-running thread.

We run with -Werror in 'make check' though. So I dont think it can
happen on PQM.
-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

[Ian Clatworthy (ian-clatworthy)]

Confirmed in 0.16 and still there immediately prior to 0.17 rc1 packaging. I would be good to clean this up soon.

[Martin Pool (mbp)]

See also bug 137387

[Martin Pool (mbp)]

I'm committing a change that makes the __del__ method just give a warning but not unlock. Combined with Robert's patch to keep a list of held locks in tests it should eliminate this problem. At any rate we do not generally get these warnings unless something else is already failing, so I'm going to mark this closed.