> "Bert Huijben" <b...@qqmail.nl> writes: > >> You get in this branch if a previous atomic initialization call failed: the >> callback function failed and returned an error. This result is then ignored >> in some code paths. >> >> It is most likely not caused by the atomic operations failing itself, but >> more likely by an initialization error in a third party library. > > Ah, yes! When we first open/read the rep-cache during the commit the > failure is not treated as a hard error. The subsequent open in the > post-commit then returns the atomic error. > > If the rep-cache has been setup you should see: > > $ sqlite3 repo/db/rep-cache.db "select * from sqlite_master" > table|rep_cache|rep_cache|3|CREATE TABLE rep_cache ( hash TEXT NOT NULL > PRIMARY KEY, revision INTEGER NOT NULL, offset INTEGER NOT NULL, size > INTEGER NOT NULL, expanded_size INTEGER NOT NULL ) > index|sqlite_autoindex_rep_cache_1|rep_cache|4| > > I suspect you will see no output because init_sqlite has failed. > > I see you are using --with-sqlite=/usr/local. Did you build sqlite with > thread support? We should check which sqlite is being picked at > runtime: either use "ldd executable" or identify the process ID and grep > through /proc/NNN/maps, look libsqlite.
The sqlite command worked (I see the expected output), but I suspect that's because the rep-cache.db file was already there (since 1.6.12). If I move it, though, the file is NOT recreated. greping through /proc/xxx/maps gives me the following: 2a96fc4000-2a97058000 r-xp 00000000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6 2a97058000-2a97158000 ---p 00094000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6 2a97158000-2a9715c000 rw-p 00094000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6 sqlite was built with default options, but "--enable-threadsafe" defaults to "yes" if it's not used, so I guess it *is* built with thread support?
