Ryan Hunt <rhunt@hp.com> writes:
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 1075895808 (LWP 30672)]
>> 0x420744b0 in _int_free () from /lib/tls/libc.so.6
>> (gdb) bt
>> #0 0x420744b0 in _int_free () from /lib/tls/libc.so.6
>> #1 0x420734d6 in free () from /lib/tls/libc.so.6
>> #2 0x40112b69 in __os_free (dbenv=0x0, ptr=0x42131300, size=92) at
>> ../os/os_alloc.c:329
>> #3 0x4011273f in __db_mutex_free (dbenv=0x8058c00, infop=0x8058efc,
>> mutexp=0x8062418) at ../mutex/mutex.c:91
>> #4 0x40105a5e in __log_dbenv_refresh (dbenv=0x8058c00) at
>> ../log/log.c:605
>> #5 0x400e8c2e in __dbenv_refresh (dbenv=0x8058c00) at
>> ../env/env_open.c:592
>> #6 0x400e8385 in __dbenv_open (dbenv=0x8058c00, db_home=0x8055048
>> "/svn/db", flags=161825, mode=438) at ../env/env_open.c:328
>> #7 0x400396b1 in svn_fs_berkeley_recover (path=0x8054ef8 "/svn/db",
>> pool=0x8054c08) at subversion/libsvn_fs/fs.c:806
I'd guess (I stress guess) that this is an NPTL problem, particularly
if you recently upgraded something (kernel, libc, bdb, svn). Does
your svnadmin work? Can you create a new repository?
On a *copy* of your repository (a simple "cp -a" will do) recover
might work if you remove the __db.nnn files, but that's another
guess. Of course, you will need a working svnadmin.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 23 18:36:49 2004