Bug 1759

Summary: OperationalError: database is locked
Product: [Build System, Metadata & Runtime] BitBake Reporter: Beth Flanagan <elizabeth.flanagan>
Component: bitbakeAssignee: Joshua Lock - Disabled <josh>
Status: RESOLVED FIXED QA Contact:
Severity: critical    
Priority: High CC: elizabeth.flanagan, josh, poky.bs.watcher, poky.watcher, richard.purdie, sgw
Version: 1.0   
Target Milestone: 1.0 PointRelease   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---

Description Beth Flanagan 2011-11-07 16:36:08 UTC
Narrowed down and able to consistently repeat on OpenSuse 11.4/Python 2.7/sqlite3 2.6.0:

bitbake poky-image-minimal poky-image-sato
Pseudo is not present but is required, building this first before the main build
NOTE: Error expanding variable WORKDIR                                                                                                                                        | ETA:  --:--:--
ERROR: Error parsing /srv/home/eflanagan/poky/meta/recipes-graphics/xorg-lib/libx11_git.bb: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception OperationalError: database is locked
ERROR: Command execution failed: Exited with 1
eflanagan@autobuilder01:~/poky/build> env|grep PYTHON
PYTHONSTARTUP=/etc/pythonstart

----------------

Interesting issues:
1. Only occurs during first run. Subsequent runs do not have this issue
2. Does not occur during a strace of bitbake .....
3. Only occurring on the autobuilders

Obviously an issue with sqlite3 and bitbake here. The best thought I have for why it doesn't occur during a strace is that we're seeing a timing issue here.
Comment 1 Joshua Lock - Disabled 2011-11-08 08:43:24 UTC
Richard's intuition is that this error is caused by a floating SRCREV. Following this lead today.
Comment 2 Joshua Lock - Disabled 2011-11-08 12:04:16 UTC
Frustratingly I can't reproduce this on a stock OpenSUSE 11.4 install (with updates), I don't see any relevant floating SRCREV's yet either.
Comment 3 Joshua Lock - Disabled 2011-11-08 12:56:50 UTC
Workaround pushed to my bernard branch: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=josh/bernard&id=85c18bd1f093011f711e3c43ff93d48e6a9c9c7e
Comment 4 Beth Flanagan 2011-11-13 22:21:03 UTC
Fixed in bernard.
Comment 5 Beth Flanagan 2011-11-14 11:15:47 UTC
Reopening as 85c18bd1f093011f hasn't been pulled into bernard
Comment 6 Joshua Lock - Disabled 2011-11-15 16:19:44 UTC
Update subject to reflect that this isn't OpenSuse specific.
Comment 7 Beth Flanagan 2011-11-15 23:13:39 UTC
Were you able to replicate it outside of Opensuse?
Comment 8 Richard Purdie 2011-11-21 02:34:49 UTC
I'm going to mark this as resolved since the pressing issue of failures has been identified and fixed for Barnard. There is a separate bug open for investigating why such large timeouts are required (http://bugzilla.pokylinux.org/show_bug.cgi?id=1761).