Failure to properly remove .bzr\checkout\lock\held causes the next bzr writing command to hang indefinitely

Bug #620870 reported by Philip Peitsch
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
Medium
Unassigned

Bug Description

I had an instance where the .bzr\checkout\lock\held folder was not removed (I don't know how this happened... potentially virus scanner related). I found subsequent write calls (e.g., bzr shelve, bzr up) would simply hang indefinitely with no error messages or timeouts, including no warnings about existing locks. This was on bzr 2.1.1.

I retried on 2.2.0 (by simply manually creating the held folder) and it crashes with "UnboundLocalError: local variable 'lock_url' referenced before assignment". I'm not to worried by that behaviour however, as it at least does something after a few seconds as opposed to 2.1.1

Martin Pool (mbp)
Changed in bzr:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
John A Meinel (jameinel) wrote : Re: [Bug 620870] [NEW] Failure to properly remove .bzr\checkout\lock\held causes the next bzr writing command to hang indefinitely

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/19/2010 10:57 PM, Philip Peitsch wrote:
> Public bug reported:
>
> I had an instance where the .bzr\checkout\lock\held folder was not
> removed (I don't know how this happened... potentially virus scanner
> related). I found subsequent write calls (e.g., bzr shelve, bzr up)
> would simply hang indefinitely with no error messages or timeouts,
> including no warnings about existing locks. This was on bzr 2.1.1.
>
> I retried on 2.2.0 (by simply manually creating the held folder) and it
> crashes with "UnboundLocalError: local variable 'lock_url' referenced
> before assignment". I'm not to worried by that behaviour however, as it
> at least does something after a few seconds as opposed to 2.1.1
>
> ** Affects: bzr
> Importance: Undecided
> Status: New
>

By default, we waited 5 minutes for the lock to be released before we
would fail. However, we should have been warning you that the lock was
present.

The latter failure looks like code that wanted to read the 'info' file
was failing to handle it properly when the file was not present.

Though this also might have been the problem in 2.1, since we would use
the information there to let you know who held the previous lock.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxymAMACgkQJdeBCYSNAAPmQQCgxFMwFk00aP4yuugR7RcgPl+E
xowAnjAy9zsobsIlF5DrS3jvi7rC1Ou7
=HRPN
-----END PGP SIGNATURE-----

Jelmer Vernooij (jelmer)
tags: added: locking
Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.