Bazaar

empty lock info file causes crash in _parse_info

Bug #185103 reported by Monty Taylor
76
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Bazaar
Fix Released
High
Martin Pool
Bazaar 2.0.5

Bug Description

If Bazaar is interrupted at some points while taking a branch, it can leave behind an empty lock info file. The empty file causes a traceback when trying to do any other write operation on the branch, including trying to break the lock. We would probably get a similar failure if the lock info file is missing.

As a workaround, manually remove the 'held' directory inside the lock directory.

We should instead handle this as a special type of dead lock.

----

On a Bazaar Branch Format 6 (bzr 0.15) branch that has lock files, running bzr info -v produces the following:

bzr arguments: [u'info', u'-v']
looking for plugins in /home/mtaylor/.bazaar/plugins
looking for plugins in /usr/lib/python2.5/site-packages/bzrlib/plugins
Plugin name __init__ already loaded
Plugin name __init__ already loaded
encoding stdout as sys.stdout encoding 'UTF-8'
opening working tree '/home/mtaylor/src/ndb-connectors-borked/devel'
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 806, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 762, in run_bzr
    ret = run(*run_argv)
  File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 492, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 772, in ignore_pipe
    result = func(*args, **kwargs)
  File "/usr/lib/python2.5/site-packages/bzrlib/builtins.py", line 1095, in run
    verbose=noise_level, outfile=self.outf)
  File "/usr/lib/python2.5/site-packages/bzrlib/info.py", line 343, in show_bzrdir_info
    outfile)
  File "/usr/lib/python2.5/site-packages/bzrlib/info.py", line 367, in show_component_info
    _show_locking_info(repository, branch, working, outfile)
  File "/usr/lib/python2.5/site-packages/bzrlib/info.py", line 179, in _show_locking_info
    if (repository.get_physical_lock_status() or
  File "/usr/lib/python2.5/site-packages/bzrlib/repository.py", line 702, in get_physical_lock_status
    return self.control_files.get_physical_lock_status()
  File "/usr/lib/python2.5/site-packages/bzrlib/lockable_files.py", line 286, in get_physical_lock_status
    return self._lock.peek() is not None
  File "/usr/lib/python2.5/site-packages/bzrlib/lockdir.py", line 418, in peek
    info = self._read_info_file(self._held_info_path)
  File "/usr/lib/python2.5/site-packages/bzrlib/lockdir.py", line 408, in _read_info_file
    return self._parse_info(self.transport.get(path))
  File "/usr/lib/python2.5/site-packages/bzrlib/lockdir.py", line 445, in _parse_info
    return read_stanza(info_file.readlines()).as_dict()
AttributeError: 'NoneType' object has no attribute 'as_dict'

return code 4

See original description
Tags: lockdir

Related branches

lp:~mbp/bzr/185103-2.0-lockdir-info
John A Meinel: Approve
Vincent Ladeuil: Approve
Diff: 114 lines (+44/-8)
3 files modified
NEWS (+5/-0)
bzrlib/lockdir.py (+19/-7)
bzrlib/tests/test_lockdir.py (+20/-1)
Revision history for this message
Martin Pool (mbp) wrote :

Thanks for the report Monty

If you still have this branch, could you please save it.

I suspect that there is a lock/held/ directory that contains an empty, missing, or malformed file; if there is can you please post it to this bug?

Changed in bzr:
assignee: nobody → mbp
importance: Undecided → Medium
status: New → Incomplete
Revision history for this message
Monty Taylor (mordred) wrote : Re: [Bug 185103] Re: bzr info -v produces a traceback

Hey Martin,

lifeless was helping me look at this some on #irc earlier. I've got a
tarball of my whole tree, but it's 130M. Do you want me to upload it
anyway?

Monty

Martin Pool wrote:
> Thanks for the report Monty
>
> If you still have this branch, could you please save it.
>
> I suspect that there is a lock/held/ directory that contains an empty,
> missing, or malformed file; if there is can you please post it to this
> bug?
>
> ** Changed in: bzr
> Importance: Undecided => Medium
> Assignee: (unassigned) => Martin Pool (mbp)
> Status: New => Incomplete
>

Revision history for this message
Martin Pool (mbp) wrote :

On 23/01/2008, Monty Taylor <email address hidden> wrote:
> Hey Martin,
>
> lifeless was helping me look at this some on #irc earlier. I've got a
> tarball of my whole tree, but it's 130M. Do you want me to upload it
> anyway?

I was going to start with just the lock files. But if lifeless was
already partway through diagnosing it, it's probably easier to just
continue with him.

--
Martin

Revision history for this message
Robert Collins (lifeless) wrote :

On Wed, 2008-01-23 at 00:43 +0000, Martin Pool wrote:
> On 23/01/2008, Monty Taylor <email address hidden> wrote:
> > Hey Martin,
> >
> > lifeless was helping me look at this some on #irc earlier. I've got a
> > tarball of my whole tree, but it's 130M. Do you want me to upload it
> > anyway?
>
> I was going to start with just the lock files. But if lifeless was
> already partway through diagnosing it, it's probably easier to just
> continue with him.

I was helping get Monty working again with a damaged tree (which appears
to be xfs ordering-writes-differently-to-bzr and a power-off combining
spectacularly badly).

I share your assessment Martin, but I have no extra detail or info on
this.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Revision history for this message
Monty Taylor (mordred) wrote : Re: bzr info -v produces a traceback
Revision history for this message
Martin Pool (mbp) wrote :

If an xfs machine crashes or abruptly shuts down then afaik all bets are off as to what gets to disk.

However, I would say that at least bzr info (and maybe bzr break-lock?) should be robust if the lock directory is broken, and just tell the user so.

Changed in bzr:
status: Incomplete → New
Revision history for this message
Martin Pool (mbp) wrote : Re: empty lock info file gives traceback from bzr info and other operations

Similar report here: https://lists.ubuntu.com/archives/bazaar/2008q1/037164.html

Martin Pool (mbp)
Changed in bzr:
status: New → Confirmed
Revision history for this message
Martin Pool (mbp) wrote :

It would be nice to give a cleaner error, but because we're already in a situation where the filesystem has lost data, giving a traceback is not so unreasonable.

Changed in bzr:
importance: Medium → Wishlist
assignee: Martin Pool (mbp) → nobody
Martin Pool (mbp)
Changed in bzr:
importance: Wishlist → High
assignee: nobody → Martin Pool (mbp)
summary: - empty lock info file gives traceback from bzr info and other operations
+ empty lock info file causes crash in _parse_info
description: updated
tags: added: lockdir
Revision history for this message
Martin Pool (mbp) wrote :

Proposed fix in https://code.edge.launchpad.net/~mbp/bzr/185103-2.0-lockdir-info/+merge/20110

Changed in bzr:
status: Confirmed → In Progress
Vincent Ladeuil (vila)
Changed in bzr:
milestone: none → 2.0.5
status: In Progress → Fix Released
Revision history for this message
bernij (bernij) wrote :

I had [what looks like] a very similar/same issue with 2.1.0, see bug 537127.

Normal operation could be recovered, without damage to the tree, by removing both directories:
.bzr/branch/lock/held
.bzr/checkout/lock/held

I noticed that:
- had tried removing the two held directories one at a time, but got traceback until both where removed
- bzr info was working, although it suggested everything was fine ... should it mention the stale held directories? and possibly suggest to remove them if appropriate?
- bzr break-lock also resulted in a traceback

Revision history for this message
Martin Pool (mbp) wrote : Re: [Bug 185103] Re: empty lock info file causes crash in _parse_info

On 12 March 2010 18:13, bernij <email address hidden> wrote:
> I had [what looks like] a very similar/same issue with 2.1.0, see bug
> 537127.
>
> Normal operation could be recovered, without damage to the tree, by removing both directories:
> .bzr/branch/lock/held
> .bzr/checkout/lock/held

Yes, that sounds like the same bug.

> I noticed that:
> - had tried removing the two held directories one at a time, but got traceback until both where removed

That makes sense.

> - bzr info was working, although it suggested everything was fine ... should it mention the stale held directories? and possibly suggest to remove them if appropriate?

I think there's a separate bug asking that info should tell you about
held locks.

> - bzr break-lock also resulted in a traceback

That should be fixed too.

By the way, do you know anything about the actions leading up to this
point? Was a previous command interrupted by a network outage or
crash?

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

Revision history for this message
bernij (bernij) wrote :

> By the way, do you know anything about the actions leading up to this
> point? Was a previous command interrupted by a network outage or
> crash?

Yes, most likely both. I am quite sure that I was doing a bzr pull while apt-get was upgrading a bunch of packages among which wpasupplicant ... the system frozen during this apt-get and after loosing both kbd and mse I rebooted by a HW power-off (>10s power button press).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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