Couldn't perform atomic initialization

[Anonymous]

After upgrading Subversion to 1.6.0_2, trac 0.11.4 fails with:

Warning: Can't synchronize with the repository (Couldn't open
Subversion repository /usr/home/svn/test1: SubversionException:
("Couldn't perform atomic initialization", 200029)). Look in the Trac log for more information.

FreeBSD 7.1

See also: ​svnissue:3387 (fixed in Subversion 1.6.2)

[Christian Boos]

Thanks for the notice. I don't think there's anything we can do besides warning people that Trac doesn't support SVN 1.6.0 on the FreeBSD platform.

Looks like 1.6.1 is on the way, so don't hesitate to update this ticket if this new version solves the problem.

Also, you'd better report the problem to the people maintaining Subversion on FreeBSD.

[mlusetti@…]

Would you mind to explain what peculiarity has "SVN 1.6.0 on the FreeBSD platform" which makes it different from others?

Regards

[Remy Blank]

I have seen something similar with SVN 1.6 on Windows, while trying to set up a build slave. The unit tests were failing consistently. I haven't kept the errors, and have since downgraded to 1.5.x (my goal was to get the build slave going, not to debug Trac with SVN 1.6).

I'll try again next time I tweak the Windows build slave.

[mlusetti@…]

So the problem is just with SVN 1.6 ? Is 0.11 which isn't compatible with svn 1.6 ?

Regards

[Alex Unigovsky <unik@…>]

Just updated to 1.6.1. Same issue (in addition to previous error I received the following error:

TracError: Couldn't open Subversion repository /var/svn/repos/npsessd: SubversionException: ('Could not configure SQLite', 200030)
}}}. This is on Gentoo Linux, py2.6, trac-multirepo).
The problem is not with subversion binary/library, but with on-disk format. Creating a repo with svnadmin create --fs-type fsfs --pre-1.6-compatible /path/to/repo helped, and a sync worked like a charm.

FYI: you can dump the repo with "svnadmin dump", recreate it as a compatible format, and reload the contents with "svnadmin load". You'll lose all the hooks etc., so better make backups.

[Alex Unigovsky <unik@…>]

Oh, crap. Sorry for misformatting. Here's the correct text:

Just updated to 1.6.1. Same issue (in addition to previous error I received the following error:

TracError: Couldn't open Subversion repository /var/svn/repos/npsessd: SubversionException: ('Could not configure SQLite', 200030)

This is on Gentoo Linux, py2.6, trac-multirepo). The problem is not with subversion binary/library, but with on-disk format. Creating a repo with svnadmin create —fs-type fsfs —pre-1.6-compatible /path/to/repo helped, and a sync worked like a charm.

FYI: you can dump the repo with "svnadmin dump", recreate it as a compatible format, and reload the contents with "svnadmin load". You'll lose all the hooks etc., so better make backups.

[Christian Boos]

Replying to Alex Unigovsky <unik@…>:

… Just updated to 1.6.1. Same issue (in addition to previous error I received the following error: TracError: Couldn't open Subversion repository /var/svn/repos/npsessd: SubversionException: ('Could not configure SQLite', 200030)

Interesting, that one might be an incompatibility between the SQLite version now used by Subversion and the one used by PySqlite. Make sure you're using the same SQLite library when building them.

[mlusetti@…]

I've built everything from ports system (FreeBSD) so I'm pretty sure they both use the same version. FYI here they are:

• sqlite3-3.6.11 (​http://www.freshports.org/databases/sqlite3)
• subversion-1.6.0_2 (​http://www.freshports.org/devel/subversion)
• py25-sqlite3-2.5.4_1 (​http://www.freshports.org/databases/py-sqlite3)

Regards

[Christian Boos]

Replying to mlusetti@…:

I've built everything from ports system (FreeBSD) so I'm pretty sure they both use the same version.

How sure? subversion-deps-1.6.0.tar.bz2 contains a "private" copy of SQLite:

$ grep define.SQLITE_VERSION subversion-deps-1.6.0/sqlite-amalgamation/sqlite3.h
#define SQLITE_VERSION         "3.6.11"

In case Subversion was built with that (the default) instead of the system SQLite, then you end up with another copy of SQLite in your binary.

A similar thing can happen with Python and PySqlite. One way to be really sure about what's going on is to issue a couple of ldd commands on the libraries.

e.g. for PySqlite:

# ldd /opt/python-2.4.4/lib/python2.4/site-packages/pysqlite2/_sqlite.so
        libsqlite3.so.0 => /opt/sqlite-3.3.8/lib/libsqlite3.so.0 (0x0000002a9566b000)

Do the same for Subversion (I don't know which of the .so's is supposed to link with sqlite, probably libsvn_fs_fs-1.so, so verify them all - I'll built it myself soon, so I'll be able to give more precision on that).

If both show the same libsqlite3 library, then there's a more serious problem than a SQLite incompatibility.

If they show a different library, or if only one or even none of them show a library, then it's very likely an incompatibility problem.

A typical scenario would be Subversion using its amalgamation copy (3.6.11), so you wouldn't find any library dependency for Subversion, and PySqlite would use the "system" SQLite. Even if by chance the version of the system SQLite would be also 3.6.11, I'm not sure this would work (different mappings for data segments).

[mlusetti@…]

FreeBSD ports system configure the builds of application for you to install and let you customize a lot of aspects (in case you want or need)

Anyway here it is bot ldd from python binding and subversion:

/usr/local/lib/libsvn_fs-1.so:

libsvn_fs_fs-1.so.0 ⇒ /usr/local/lib/libsvn_fs_fs-1.so.0 (0x28188000) libsvn_fs_base-1.so.0 ⇒ /usr/local/lib/libsvn_fs_base-1.so.0 (0x281ab000) libsvn_delta-1.so.0 ⇒ /usr/local/lib/libsvn_delta-1.so.0 (0x281d3000) libsvn_subr-1.so.0 ⇒ /usr/local/lib/libsvn_subr-1.so.0 (0x28300000) libsvn_fs_util-1.so.0 ⇒ /usr/local/lib/libsvn_fs_util-1.so.0 (0x281dd000) libapr-1.so.3 ⇒ /usr/local/lib/libapr-1.so.3 (0x28345000) libcrypt.so.4 ⇒ /lib/libcrypt.so.4 (0x28369000) libthr.so.3 ⇒ /lib/libthr.so.3 (0x281e8000) libintl.so.8 ⇒ /usr/local/lib/libintl.so.8 (0x28382000) libc.so.7 ⇒ /lib/libc.so.7 (0x28080000) libaprutil-1.so.3 ⇒ /usr/local/lib/libaprutil-1.so.3 (0x2838b000) libdb41.so.1 ⇒ /usr/local/lib/libdb41.so.1 (0x283a7000) libexpat.so.6 ⇒ /usr/local/lib/libexpat.so.6 (0x28456000) libiconv.so.3 ⇒ /usr/local/lib/libiconv.so.3 (0x28476000) libz.so.4 ⇒ /lib/libz.so.4 (0x2856b000) libsqlite3.so.8 ⇒ /usr/local/lib/libsqlite3.so.8 (0x2857d000)

/usr/local/lib/python2.5/site-packages/_sqlite3.so:

libsqlite3.so.8 ⇒ /usr/local/lib/libsqlite3.so.8 (0x28300000) libthr.so.3 ⇒ /lib/libthr.so.3 (0x28190000) libc.so.7 ⇒ /lib/libc.so.7 (0x28080000)

As you can see both depends on /usr/local/lib/libsqlite3.so.8

Thanks for your interest.

[mlusetti@…]

Ops… is see something gets corrupted in the markup. Here another try:

/usr/local/lib/libsvn_fs-1.so:
	libsvn_fs_fs-1.so.0 => /usr/local/lib/libsvn_fs_fs-1.so.0 (0x28188000)
	libsvn_fs_base-1.so.0 => /usr/local/lib/libsvn_fs_base-1.so.0 (0x281ab000)
	libsvn_delta-1.so.0 => /usr/local/lib/libsvn_delta-1.so.0 (0x281d3000)
	libsvn_subr-1.so.0 => /usr/local/lib/libsvn_subr-1.so.0 (0x28300000)
	libsvn_fs_util-1.so.0 => /usr/local/lib/libsvn_fs_util-1.so.0 (0x281dd000)
	libapr-1.so.3 => /usr/local/lib/libapr-1.so.3 (0x28345000)
	libcrypt.so.4 => /lib/libcrypt.so.4 (0x28369000)
	libthr.so.3 => /lib/libthr.so.3 (0x281e8000)
	libintl.so.8 => /usr/local/lib/libintl.so.8 (0x28382000)
	libc.so.7 => /lib/libc.so.7 (0x28080000)
	libaprutil-1.so.3 => /usr/local/lib/libaprutil-1.so.3 (0x2838b000)
	libdb41.so.1 => /usr/local/lib/libdb41.so.1 (0x283a7000)
	libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x28456000)
	libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28476000)
	libz.so.4 => /lib/libz.so.4 (0x2856b000)
	libsqlite3.so.8 => /usr/local/lib/libsqlite3.so.8 (0x2857d000)

/usr/local/lib/python2.5/site-packages/_sqlite3.so:
	libsqlite3.so.8 => /usr/local/lib/libsqlite3.so.8 (0x28300000)
	libthr.so.3 => /lib/libthr.so.3 (0x28190000)
	libc.so.7 => /lib/libc.so.7 (0x28080000)

[Christian Boos]

I did some more investigations on the issue, there's indeed a bug … and a fix.

Replying to cboos:

Replying to Alex Unigovsky <unik@…>:

… Just updated to 1.6.1. Same issue (in addition to previous error I received the following error: TracError: Couldn't open Subversion repository /var/svn/repos/npsessd: SubversionException: ('Could not configure SQLite', 200030)

Actually that error has been fixed in svn trunk: ​http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_subr/sqlite.c?r1=37184&r2=37185

Interesting, that one might be an incompatibility between the SQLite version now used by Subversion and the one used by PySqlite. Make sure you're using the same SQLite library when building them.

… and contrary to my expectations, it seems quite possible to mix SQLite versions at runtime. The following table summarizes my tests.

The first column lists the Pysqlite builds and the SQLite versions they were compiled against.

The first row lists the Subversion 1.6.1 builds and the SQLite versions they were compiled against.

Each cell shows the result of the test and the SQLite version(s) actually used at runtime for Pysqlite and Subversion respectively. When both Pysqlite and Subversion where built against a dynamic SQLite library, I put the SQLite version matching the one PySqlite was compiled with first in the LD_LIBRARY_PATH (i.e. the row uses the version shown in bold).

	Subversion 1.6.1 sqlite-amalgamation 3.6.11 static	Subversion 1.6.1 --with-sqlite 3.4.2 dynamic	Subversion 1.6.1 --with-sqlite 3.6.13 dynamic
PySqlite 2.5.1 sqlite 3.6.13 static	OK (3.6.13 static/3.6.13 static)	OK (3.6.13 static/3.4.2 dynamic)	OK (3.6.13 static/3.6.13 dynamic)
PySqlite 2.4.1 sqlite 3.4.2 dynamic	OK (3.4.2 dynamic/3.6.13 static)	OK (same 3.4.2 dynamic)	FAIL (3.4.2 misses some symbols that 3.6.13 needs - that's an expected failure)
PySqlite 2.4.1 sqlite 3.6.13 dynamic	OK (3.6.13 dynamic/3.6.13 static)	OK (same 3.6.13 dynamic)	FAIL (same 3.6.13 dynamic)

FAIL with the scary ("Couldn't perform atomic initialization", 200029) with pristine 1.6.1, but OK with the r37185 patch above applied.

Some explanations about why other configurations work:

• Subversion 1.6.1 --with-sqlite 3.4.2 dynamic works fine at runtime with SQLite 3.6.13, as the problematic code fixed by r37185 is simply not compiled in.
• Subversion 1.6.1 --with-sqlite 3.6.13 dynamic works fine when used with PySqlite built in amalgamation mode, as it's not the same "sqlite" that will be initialized (so no SQLITE_MISUSE result in this case)
• similarly, Subversion 1.6.1 with sqlite-amalgamation 3.6.13 static works always, as it is able to deal with its own library version without mixing up with PySqlite's one (this was the situation I feared, but apparently it works fine)

Note that one can also get the same error if SQLite was built without thread-safe support (i.e. with --enable-threadsafe=no, which fortunately is not anymore the default these days).

So it's a svn issue, let's hope they fix it for 1.6.2 (I'll close the ticket once a Subversion version with the fix has been released).

[Christian Boos]

The fix will be in Subversion 1.6.2 (​svncset:875825). Thanks to Arfrever for the fix and to Hyrum for the port to 1.6.x.

[anonymous]

Has this been resolved in 1.6.2? I am currently receiving the exact same atomic error after building everything that was current/stable as of yesterday.

[Christian Boos]

Replying to anonymous:

Yes, the fix is in 1.6.2 (and still in 1.6.3 - you just made me check ;-) ).

However, when I built 1.6.3 yesterday, it was with sqlite-amalgamation (3.6.13), so the bug can't happen according to comment:13.

The information you gave is not enough to see if this is the same problem or a different one. We need to see an informative error message, like the one in comment:6. Also, double check your subversion/libsvn_subr/sqlite.c file and see if it is up to date (search for SQLITE_MISUSE).

[Dave Ariens <dave@…>]

(Removing Anonymity)

Hi!

Where can I look for an informative error message? my trac.log is empty, and all i receive is the error within the trac web UI…. I also never specified a —with-sqlite flag for compiling subversion, so I'm unsure if this should be an issue or not.

[Christian Boos]

The error in comment:6 was directly in the Trac error message… I seem to remember that the "Couldn't perform atomic initialization" error would follow the 'Could not configure SQLite' one, but the former is a more general error, so there might be another cause for this error.

In all cases, gdb is your friend here, see TracTroubleshooting#SystemErrors. Put a breakpoint where the "atomic initialization" error is raised (in svn_atomic__init_once, file subversion/libsvn_subr/atomic.c, near line 62), wait for the breakpoint to be hit, then do a bt to see from where you come from.

[Christian Boos]

(clearing report:35)