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

Re: Berkeley DB error while creating environment for filesystem

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-07-31 06:12:51 CEST

> I have a different Linux box where I want to run the subversion
> server and this machine does not have the same version of shared
> libraries etc so I run configure again with the "all static" flag to
> produce subversion executables with statically linked libraries.

The short answer is: Red Hat's native static libdb won't work with
Subversion.

Here's the long answer, explained as clearly as I can manage:

Red Hat builds its native DB library with --enable-posixmutexes,
meaning that DB performs locking by mapping a shared memory area,
treating part of it as a pthread_mutex_t, and locking and unlocking
it using pthread_mutex_lock and pthread_mutex_unlock.

For this to work for multiple processes sharing the same database, DB
needs its pthread mutexes to be "inter-process" mutexes, as opposed to
the normal kind which only work within a single process. It calls
pthread_mutexattr_setpshared(&att, PTHREAD_PROCESS_SHARED) to set this
up.

The catch is: the old Linux thread library doesn't support
inter-process mutexes. You need NPTL support for them to work.
Normally, this isn't a big deal; the Red Hat kernel has NPTL support,
the dynamic linker detects that the kernel has NPTL support and uses
the NPTL pthreads library, and it all works.

But when you link statically, you never get NPTL support, which means
you can't get inter-process mutexes, which means DB can't work unless
you pass it the DB_PRIVATE flag (which Subversion doesn't, because
it's very keen on letting multiple processes use the DB).

There is a slight difference in behavior between version of Red Hat in
this department: in Red Hat 9, RHEL3, and earlier Fedora Core, you get
a "Function not implemented" error trying to use the static system db
library with Subversion, because it tries to invoke
pthread_mutexattr_setshared on a mutexattr structure and fails. In
later Fedora Core, the mismatch is detected earlier on and you get an
"Invalid argument" error with a verbose error of "Berkeley DB library
configured to support only DB_PRIVATE environments". (Unfortunately,
we do not display verbose BDB errors at this time; Max Bowsher has a
patch in the works to fix that.)

There have been a lot of misunderstandings about Red Hat's BDB NPTL
issues, so rather than ask anyone to take my word for it, here are
some test programs you have use to verify some of my assertions.
First, a pthreads test program:

#include <stdio.h>
#include <pthread.h>

int main()
{
  pthread_mutexattr_t att;

  printf("%d\n", pthread_mutexattr_init(&att));
  printf("%d\n", pthread_mutexattr_setpshared(&att, PTHREAD_PROCESS_SHARED));
  return 0;
}

If you compile this normally ("cc test.c -lpthread") and run it,
you'll see the answers 0 and 0, indicating success. If you compile it
statically ("cc -static test.c -lpthreads") and run it, you'll see 0
and 38, where 38 is the errno value for "Function not implemented".

Second, a BDB test program:

#include <stdio.h>
#include <db.h>

int main()
{
  DB_ENV *env;

  printf("%d\n", db_env_create(&env, 0));
  printf("%d\n", env->open(env, ".", DB_CREATE|DB_INIT_LOCK|DB_INIT_LOG
                           |DB_INIT_MPOOL|DB_INIT_TXN, 0666));
  return 0;
}

If you compile this normally ("cc test.c -ldb") and run it, you'll see
the answers 0 and 0, indicating success. If you compile it statically
("cc -static test.c -ldb-4.1 -lpthread", or "-ldb-4.2" on FC2) and run
it, you'll see 0 and either 38 or 22 (ENOSYS or EINVAL) depending on
the version of Red Hat.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 31 06:13:12 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.