RemoteBranch.lock_read() doesn't lock the underlying repository
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Fix Released
|
High
|
Andrew Bennetts |
Bug Description
Bazaar 1.6b1, Ubuntu 8.04
> bzr check bzr+ssh:
Server does not understand Bazaar network protocol 3, reconnecting. (Upgrade the server to avoid this.)
bzr: ERROR: bzrlib.
Traceback (most recent call last):
File "/usr/lib/
return run_bzr(argv)
File "/usr/lib/
ret = run(*run_argv)
File "/usr/lib/
return self.run(
File "/usr/lib/
check(
File "/usr/lib/
branch_result = branch.check()
File "/usr/lib/
return unbound(self, *args, **kwargs)
File "/usr/lib/
last_
File "/usr/lib/
parents = graph.get_
File "/usr/lib/
new_parents = self._real_
File "/usr/lib/
self.
File "/usr/lib/
raise errors.
ObjectNotLocked: KnitPackReposit
bzr 1.6b1 on python 2.5.2 (linux2)
arguments: ['/usr/bin/bzr', 'check', 'bzr+ssh:
encoding: 'UTF-8', fsenc: 'UTF-8', lang: 'en_NZ.UTF-8'
plugins:
launchpad /usr/lib/
loom /home/mpt/
lpreview /home/mpt/
pqm /home/mpt/
*** Bazaar has encountered an internal error.
Please report a bug at https:/
including this traceback, and a description of what you
were doing when the error occurred.
"bzr cat" produces a similar traceback (originally reported in bug 175570).
Related branches
Changed in bzr: | |
importance: | Undecided → High |
status: | New → Confirmed |
description: | updated |
Changed in bzr: | |
assignee: | nobody → spiv |
milestone: | none → 1.7 |
Something weird is happening here.
Considering that Branch.check() uses the @needs_read_lock decorator, and you can see the 'read_locked()' function in the traceback. Which means that the branch *should* be read locked, and by extension so should its repository.
Oh wait, isn't there a bug about RemoteBranch. lock_read( ) not properly locking the underlying repository?
Maybe I didn't actually get it submitted. The problem was that without doing '_ensure_real()' the RemoteBranch would fail to lock its repository. Because it assumed that self._real_branch would be locking it.
Basically a race condition. If you use an api on RemoteBranch that requires it to defer to the self._real_branch, then the repository is properly locked. As we move more functions to be over the RPC, you get more instances where that is not true, and you get failures like this.