On Wed, Feb 23, 2011 at 11:42:18AM -0700, Michael Chaffin wrote:
> C:\Temp\testdir>be init
> Traceback (most recent call last):
>   ...
>   File "C:\PROGRA~1\Python26\lib\site-packages\libbe\command\init.py", line
> 95, in _run
>     storage.init()
>   File "C:\PROGRA~1\Python26\lib\site-packages\libbe\storage\base.py", line
> 194, in init
>     return self._init()
>   File "C:\PROGRA~1\Python26\lib\site-packages\libbe\storage\vcs\base.py",
> line 602, in _init
>     self._vcs_add(self._u_rel_path(self.be_dir))
>   File "C:\PROGRA~1\Python26\lib\site-packages\libbe\storage\vcs\bzr.py",
> line 159, in _vcs_add
>     cmd.run(file_list=[path], file_ids_from=self.repo)
>   File "C:\PROGRA~1\Python26\lib\site-packages\bzrlib\commands.py", line
> 705, in run
>     return self._operation.run_simple(*args, **kwargs)
>   ...
> bzrlib.errors.LockContention: Could not acquire lock
> "C:/Temp/testdir/.bzr/checkout/dirstate":
> (32, 'CreateFileW', 'The process cannot access the file because it is being
> used by another process.')

So we're getting though the intial detection.  Looking at

    libbe.storage.vcs.base.VCS._init()

we have

    if not os.path.exists(self.repo) or not os.path.isdir(self.repo):
        raise VCSUnableToRoot(self)
    if self._vcs_detect(self.repo) == False:
        self._vcs_init(self.repo)
    if self._rooted == False:
        self.root()
    os.mkdir(self.be_dir)
    self._vcs_add(self._u_rel_path(self.be_dir))    # <---- crashes
    self._setup_storage_version()
    self._cached_path_id.init()

This means that you're succefully getting through a call to cmd_root()
and then dying on the next bzrlib Command call (cmd_add()).

> > My current theory is that it's a stale lock from previous buggy
> > crashes.  Does `bzr commit` or some other lock-aquiring command work
> > in your test directory?  Or you could just try in a fresh bzr repo.
>
> So I created this current repo this morning ... I am at revision 1
> right now. Here is a quick sessio to do a 'bzr commit'
> 
> ** SNIP **
> C:\Temp\testdir>bzr status
> unknown:
>   .be/
> 
>    <touch files testFileA.cpp and testFileB.cpp>
> 
> C:\Temp\testdir>bzr status
> modified:
>   testFileA.cpp
>   testFileB.cpp
> unknown:
>   .be/
> 
> C:\Temp\testdir>bzr commit -m "Minor changes to force commit"
> Committing to: C:/Temp/testdir/
> modified testFileA.cpp
> modified testFileB.cpp
> Committed revision 2.
> 
> C:\Temp\testdir>
> 
> ** SNIP **
> 
> So, no I think this is specific to how libbe is calling bzrlib functions on
> my machine right now

To figure this out, I ran my repo with tracing on:

    $ python -m trace --trace /home/wking/bin/be init >trace 2>&1

Looking through the trace for interesting things:

                $ grep 'bzr.py.*cmd 
=\|commands.py(705)\|cleanup.py(165)\|mutabletree.py(48)\|workingtree_4.py(622)\|dirstate.py(3065)\|lock.py(413)\|\._lock_token\|ReadLock\|WriteLock'
 trace
    ... (intialization stuff) ...
    bzr.py(139):         cmd = bzrlib.builtins.cmd_root()
    commands.py(705):                 return self._operation.run_simple(*args, 
**kwargs)
    cleanup.py(165):         result = func(*args, **kwargs)

Nothing interesting happens during cmd_root().  This next command
leads to your crash:

    bzr.py(162):         cmd = bzrlib.builtins.cmd_add()
    commands.py(705):                 return self._operation.run_simple(*args, 
**kwargs)
    cleanup.py(165):         result = func(*args, **kwargs)
    dirstate.py(393):         self._lock_token = None
    workingtree_4.py(580):                 if not state._lock_token:
    dirstate.py(3046):         if self._lock_token is not None:
    dirstate.py(3052):         self._lock_token = lock.ReadLock(self._filename)
    lock.py(242):             super(_fcntl_ReadLock, self).__init__()
    lock.py(244):             if self.filename in _fcntl_WriteLock._open_locks:
    lock.py(252):             
_fcntl_ReadLock._open_locks.setdefault(self.filename, 0)
    lock.py(253):             _fcntl_ReadLock._open_locks[self.filename] += 1
    dirstate.py(3054):         self._state_file = self._lock_token.f
    dirstate.py(393):         self._lock_token = None
    workingtree_4.py(580):                 if not state._lock_token:
    dirstate.py(3046):         if self._lock_token is not None:
    dirstate.py(3052):         self._lock_token = lock.ReadLock(self._filename)
    lock.py(242):             super(_fcntl_ReadLock, self).__init__()
    lock.py(244):             if self.filename in _fcntl_WriteLock._open_locks:
    lock.py(252):             
_fcntl_ReadLock._open_locks.setdefault(self.filename, 0)
    lock.py(253):             _fcntl_ReadLock._open_locks[self.filename] += 1
    dirstate.py(3054):         self._state_file = self._lock_token.f
    dirstate.py(3072):         if self._lock_token is None:
    dirstate.py(3080):         self._lock_token.unlock()
    lock.py(265):             count = _fcntl_ReadLock._open_locks[self.filename]
    lock.py(269):                 _fcntl_ReadLock._open_locks[self.filename] = 
count - 1
    dirstate.py(3081):         self._lock_token = None
    mutabletree.py(48):         self.lock_tree_write()
    workingtree_4.py(622):         return self._lock_self_write()
    dirstate.py(393):         self._lock_token = None
    workingtree_4.py(601):                 if not state._lock_token:
    dirstate.py(3059):         if self._lock_token is not None:
    dirstate.py(3065):         self._lock_token = lock.WriteLock(self._filename)

That last command is on your traceback.  Note that it is the first
time the process is attempting to aquire a WriteLock.

    lock.py(201):             super(_fcntl_WriteLock, self).__init__()
    lock.py(204):             if self.filename in _fcntl_WriteLock._open_locks:
    lock.py(207):             if self.filename in _fcntl_ReadLock._open_locks:
    lock.py(219):             _fcntl_WriteLock._open_locks.add(self.filename)
    dirstate.py(3067):         self._state_file = self._lock_token.f

Lock successfully opened and we're moving on through
bzrlib.dirstate.lock_write().  Your setup crashes trying to intialize
the WriteLock.  I think the reason it works for you but not for me is
a Windows/Linux difference, since the guts of bzrlib.lock are system
dependent (you're running _w32c_WriteLock).

Boiling the troublesome code down to a minimal test case we get
something like the file I've attached.  Running it on my sytem gives:

    $ python bzr-be-test.py 
    working in /tmp/tmp-bbtMJijPe
    initialize Bazaar repo
    Created a standalone tree (format: 2a)                                      
   
    create a dummy file a_file
    add the file via Python
    adding a_file
    success
    cleanup test directory

Does it also run successfully on your system?

-- 
This email may be signed or encrypted with GPG (http://www.gnupg.org).
The GPG signature (if present) will be attached as 'signature.asc'.
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
# Test bzrlib.builtins.cmd_add as called by Bugs Everywhere.

import os
import os.path
import shutil
import sys
import tempfile

import bzrlib.builtins

initial_dir = os.getcwd()
workdir = tempfile.mkdtemp(prefix='tmp-bbt')
try:
    print 'working in', workdir
    os.chdir(workdir)
    print 'initialize Bazaar repo'
    os.system('bzr init')
    new_file = 'a_file'
    print 'create a dummy file', new_file
    f = open(new_file, 'w')
    f.write('Hello, world!\n')
    f.close()
    print 'add the file via Python'
    cmd = bzrlib.builtins.cmd_add()
    cmd.outf = sys.stdout
    cmd.run([new_file], file_ids_from='.')
    print 'success'
finally:
    print 'cleanup test directory'
    os.chdir(initial_dir)
    shutil.rmtree(workdir)

Attachment: pgpo5GJiI5FZ5.pgp
Description: PGP signature

_______________________________________________
Be-devel mailing list
[email protected]
http://void.printf.net/cgi-bin/mailman/listinfo/be-devel

Reply via email to