[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Berkeley DB fails creating a new repository, "invalid argument"

From: Enrique Perez-Terron <enrique.perez-terron_at_norway.online.no>
Date: 2004-08-17 03:47:25 CEST

On Mon, 2004-08-16 at 22:51, Enrique Perez-Terron wrote:
> On Mon, 2004-08-16 at 21:56, Enrique Perez-Terron wrote:
> > # rm -rf /home-4/subversion
> > # svnadmin create /home-4/subversion
> > svn: Berkeley DB error while creating environment for filesystem /home-4/subversion/db:
> > Invalid argument
>
>
> I have found the following code in db-4.2.52/env/env_open.c (with line
> numbers):
>
> 139 #ifdef HAVE_MUTEX_THREAD_ONLY
> 140 if (!LF_ISSET(DB_PRIVATE)) {
> 141 __db_err(dbenv,
> 142 "Berkeley DB library configured to support only DB_PRIVATE environments");
> 143 return (EINVAL);
> 144 }
> 145 #endif
>
> I have then checked if the string shown appears in the relevant
> libraries, and it does. That indicates that my copy of db4 was compiled
> with -DHAVE_MUTEX_THREAD_ONLY. This will make env_open() fail with
> EINVAL unless called with DB_PRIVATE.
>
> I will subsequently check if it works to set the DB_PRIVATE flag in the
> call to env_open(), but actually, I do not (yet) understand the
> implications of doing so.

After doing some reading I (too) have found it is no good idea. It makes
subversion believe it has mutex protecion of critical sections when in
reality it has not. If there are multiple simultaneous users of a
repository, it may easily get corrupted.

I have now found that the db4 rpm installs two versions of the library,
one in /lib and one in /lib/tls. The rpm spec file only builds the tls
version if running on an architecture that supports nptl (as defined in
a static list)

However, the postinstall script makes no attempt at checking if the
present environment supports nptl, and so I am left with the notls
version of the library.

If I do a simple and naive ./configure, the script says

   checking for mutexes... x86/gcc-assembly

and the produced db-config.h says

   #define HAVE_MUTEX_THREADS 1
   #define HAVE_MUTEX_X86_GCC_ASSEMBLY 1

while the configure as run by rpm finds (in the tls case)

   checking for mutexes... (cached) POSIX/pthreads/library

and in the notls case

   checking for mutexes... (cached) POSIX/pthreads/library/private

and the corresponding contents of db_config.h is, in the tls case

   #define HAVE_MUTEX_PTHREADS 1
   #define HAVE_MUTEX_THREADS 1

and in the notls case

   #define HAVE_MUTEX_PTHREADS 1
   #define HAVE_MUTEX_THREADS 1
   #define HAVE_MUTEX_THREAD_ONLY 1

There appears to be a solution simply to ensure that the tls version of
the library is used, adding /lib/tls and /usr/lib/tls to the top of
/etc/ld.so.conf, and running ldconfig. Rolling my own rpm is perhaps
even better as the decision of the configure to use x86/gcc assembly
likely is the best choice for my architecture.

OK, now I configured the tls libs and got a new error message instead:

   svn: Berkeley DB error while creating environment for filesystem /home-4/subversion/db:
   Function not implemented

But fortunately this is in the FAQ. I need a glibc that supports nptl.
I386 does not support nptl, but i486 and i586 does. However, Fedora only
ships glibc for i386 or i686, and I cannot use i686, so I have the i386
non-nptl glibc version.

Confusion snowballs faster than any clarification.

-Enrique

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 17 05:00:00 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.