[win32] local push finished with error message: Could not acquire lock

Bug #206406 reported by Alexander Belchenko
28
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Bazaar
Fix Released
High
Robert Collins
Bazaar Explorer
Invalid
Undecided
Unassigned
QBzr
Invalid
Undecided
Unassigned

Bug Description

bzr 1.3 @ win32: local push finished with error message: Could not acquire lock
Operation almost done. Build phase is done, repository is OK,
working tree successfully created.

Here is .bzr.log

0.218 encoding stdout as sys.stdout encoding 'cp866'
0.234 bzr arguments: [u'-Derror', u'--no-plugins', u'push', u'C:\\Temp\\2']
0.297 encoding stdout as sys.stdout encoding 'cp866'
0.515 created control directory in file:///C:/Temp/2/
0.578 creating repository in file:///C:/Temp/2/.bzr/.
0.625 Using fetch logic to copy between KnitPackRepository('file:///C:/Temp/1/.bzr/repository/')(<RepositoryFormatKnitPack1>) and KnitPackRepository('file:///C:/Temp/2/.bzr/repository/')(<RepositoryFormatKnitPack1>)
0.703 creating branch <bzrlib.branch.BzrBranchFormat6 object at 0x01163390> in file:///C:/Temp/2/.bzr/
0.828 opening working tree 'C:/Temp/1'
0.875 trying to create missing lock 'C:/Temp/2/.bzr/checkout/dirstate'
0.875 opening working tree 'C:/Temp/2'
0.984 Traceback (most recent call last):
  File "bzrlib\commands.pyc", line 834, in run_bzr_catch_errors
  File "bzrlib\commands.pyc", line 790, in run_bzr
  File "bzrlib\commands.pyc", line 492, in run_argv_aliases
  File "bzrlib\builtins.pyc", line 799, in run
  File "bzrlib\bzrdir.pyc", line 219, in clone_on_transport
  File "bzrlib\decorators.pyc", line 127, in read_locked
  File "bzrlib\workingtree.pyc", line 587, in clone
  File "bzrlib\decorators.pyc", line 127, in read_locked
  File "bzrlib\workingtree.pyc", line 595, in copy_content_into
  File "bzrlib\merge.pyc", line 63, in transform_tree
  File "bzrlib\merge.pyc", line 1198, in merge_inner
  File "bzrlib\merge.pyc", line 416, in do_merge
  File "bzrlib\workingtree_4.pyc", line 1672, in lock_read
  File "bzrlib\dirstate.pyc", line 2708, in lock_read
  File "bzrlib\lock.pyc", line 293, in __init__
  File "bzrlib\lock.pyc", line 274, in _lock
LockContention: Could not acquire lock "C:/Temp/2/.bzr/checkout/dirstate"

Changed in bzr:
importance: Undecided → Critical
status: New → Confirmed
Revision history for this message
Alexander Belchenko (bialix) wrote : Re: [Bug 206406] [NEW] [win32] local push finished with error message: Could not acquire lock

Alexander Belchenko пишет:
> Public bug reported:
>
> bzr 1.3 @ win32: local push finished with error message: Could not acquire lock
> Operation almost done. Build phase is done, repository is OK,
> working tree successfully created.

This bug introduced by revno.3279 in bzr.dev:

revno: 3279
committer: Canonical.com Patch Queue Manager <email address hidden>
branch nick: +trunk
timestamp: Sat 2008-03-15 01:07:14 +0000
message:
   (jam) Implement Cherrypick support for Merge3

Revision history for this message
John A Meinel (jameinel) wrote :

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

Alexander Belchenko wrote:
| Alexander Belchenko пишет:
|> Public bug reported:
|>
|> bzr 1.3 @ win32: local push finished with error message: Could not
|> acquire lock
|> Operation almost done. Build phase is done, repository is OK,
|> working tree successfully created.
|
| This bug introduced by revno.3279 in bzr.dev:
|
| revno: 3279
| committer: Canonical.com Patch Queue Manager <email address hidden>
| branch nick: +trunk
| timestamp: Sat 2008-03-15 01:07:14 +0000
| message:
| (jam) Implement Cherrypick support for Merge3
|

I'm guessing it is just exposing a latent bug where we were not locking when we
should.

Specifically, the cherrypick requires grabbing ancestry (which would have been
required with a different merge algorithm anyway), so it needs a read-lock for a
period of time.

This would indicate that we should have either been taking out a write lock
earlier (and the read is now conflicting when we do take out a write-lock), or
something similar.

I'm not at much liberty to work on this right now, mostly because the internet
access here is quite limited. I get about 4.5KB/s for a couple of hours, which
is almost enough to get all of my email.

So my quick answer is to just check if you can get a lock taken out earlier. It
might also be that I'm taking a tree read lock, when really all I need is a
branch/repository level one.

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

iD8DBQFH7X3pJdeBCYSNAAMRAk4+AJ9Y/Y9sYjZ7oSiSGDy/cVaPP3bqCwCdHVgA
x0wU5mGJ9pHfOZWREqnmx4g=
=aQ5Y
-----END PGP SIGNATURE-----

Revision history for this message
Alexander Belchenko (bialix) wrote : Re: [Bug 206406] [NEW] [win32] local push finished with error message: Could not acquire lock

For me it's just indication how fragile OS locks: someone change cherrypicking merge logic
and eventually push becomes broken. Where there is liaison between them?

Martin Pool (mbp)
Changed in bzr:
importance: Critical → High
Revision history for this message
Laurens Simonis (laurens.s) wrote :

I'd like to let you know that this bug (or one which manifistates itself in exactly the same way) still exists.

The produced branch seems to be perfectly fine, though.

Revision history for this message
Laurens Simonis (laurens.s) wrote :

I forgot to post my version info, this is on win XP:

Bazaar (bzr) 1.5
  Python interpreter: C:\Python25\python.exe 2.5.2
  Python standard library: C:\Python25\lib
  bzrlib: C:\Python25\lib\site-packages\bzrlib
  Bazaar configuration: C:\Documents and Settings\<username>\Application Data\bazaar\2.0
  Bazaar log file: C:\Documents and Settings\<username>\My Documents\.bzr.log

Copyright 2005, 2006, 2007, 2008 Canonical Ltd.
http://bazaar-vcs.org/

bzr comes with ABSOLUTELY NO WARRANTY. bzr is free software, and
you may use, modify and redistribute it under the terms of the GNU
General Public License version 2 or later.

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

I agree, Alexander, this sort of bug is a very annoying consequence of using OS locks, and I would really hope that a future working tree format can find a way to avoid them altogether.

In general I think this happens when we have aliasing of two objects pointing to a single on disk file, and *that* typically happens when we're passing around a filename rather than an object reference. For instance the tests commonly set up a branch using the object api, but then actually run the tests through a run_bzr command line, which will try to reopen them separately.

John A Meinel (jameinel)
Changed in bzr:
assignee: nobody → jameinel
milestone: none → 1.12
status: Confirmed → Fix Committed
Revision history for this message
Martitza (martitzam) wrote :

I see this problem in bzr 1.13-1 (installed using recommended WIndows installer) on WinXP SP3 and Windows Server2003.

Revision history for this message
John A Meinel (jameinel) wrote :

The fix I have broke some other bits.
Basically, we still need to track down all the cases where we are holding a basis_tree longer than the containing working_tree's lock.

I thought there would be some easier/quicker workarounds, but it doesn't seem like it works.

Changed in bzr:
milestone: 1.12 → none
Revision history for this message
Martitza (martitzam) wrote : Re: [Bug 206406] Re: [win32] local push finished with error message: Could not acquire lock

On Sat, Apr 18, 2009 at 2:59 PM, John A Meinel <email address hidden>wrote:

> The fix I have broke some other bits.
> Basically, we still need to track down all the cases where we are holding a
> basis_tree longer than the containing working_tree's lock.
>
> I thought there would be some easier/quicker workarounds, but it doesn't
> seem like it works.
>
> ** Changed in: bzr
> Milestone: 1.12 => None
>

Thank you for your reply. KNowing is better than wondering. As you can
tell, I hoped to use 'push' to achieve efficient backups. (Imagine that
only 25 of 25,000 files in a project might change on a given day, but some
days 250 files might change.) Until 'push' is fixed on Windows, I will
probably back up the who branch with 'branch'.

But I am tempted (I know I should not be!) to use 'push' anyway, because it
seems like updates are fine (so far!) and that the problem is only with the
initial push...

Thanks
-M

John A Meinel (jameinel)
Changed in bzr:
status: Fix Committed → In Progress
Revision history for this message
Martitza (martitzam) wrote :

This issue in bzr gets fresh exposure in Bazaar Explorer (via Qbzr via bzr) now that there is a windows installer for Bazaar Explorer and there is a great big "Push" button in Bazaar Explorer. Please see attached graphic.

I see there has been some post-1.16 work on win32 file locks -- getting locks on creation rather than relying on sharing semantics. Any chance this addresses this issue and will appear in 1.17 ?

Revision history for this message
Alexander Belchenko (bialix) wrote :

Martitza, it's a core problem in using OS locks on Windows. Recent changes in OS locks does not address it IIUC, because this problem is about inability to change read access to write access.

Poke core devs poolie and jam in IRC about this bug. It's almost 1.5 years old!!!

Changed in qbzr:
status: New → Invalid
Changed in bzr-explorer:
status: New → Invalid
Revision history for this message
Alexander Belchenko (bialix) wrote : Re: [Bug 206406] Re: [win32] local push finished with error message: Could not acquire lock

Martitza пишет:
> This issue in bzr gets fresh exposure in Bazaar Explorer (via Qbzr via bzr) now that there is a windows installer for Bazaar Explorer and there is a great big "Push" button in Bazaar Explorer. Please see attached graphic.

BTW, the push itself works long enough to create destination branch. So this error is really
annoying, but mostly harmless.

tags: added: dirstate2
Revision history for this message
John A Meinel (jameinel) wrote :

I think this was fixed a while ago with Robert's 'shelve' fix back for 2.0.0. At the very least doing "bzr push ../existing_tree" works without failure now.

Changed in bzr:
assignee: John A Meinel (jameinel) → Robert Collins (lifeless)
milestone: none → 2.1.0b4
status: In Progress → Fix Released
Revision history for this message
Alexander Belchenko (bialix) wrote :

John A Meinel пишет:
> I think this was fixed a while ago with Robert's 'shelve' fix back for
> 2.0.0. At the very least doing "bzr push ../existing_tree" works without
> failure now.

There was 2 fixes from Robert landed in 1.18 (or 1.18.1): one for shelve, second for push.

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.