> -----Original Message-----
> From: Brandon Ehle [mailto:azverkan@yahoo.com]
> Sent: Thursday, January 09, 2003 1:44 AM
> To: Peter Howard
> Cc: Subversion Dev list
> Subject: Re: Repository "hung"
>
>
> >
> >
> >I was wrong there. Going back through the lsof output, it
> consistently gets
> >to log.0000000094, then spends a long time with just the files
> above (or a
> >subset) open, before hitting a segmentation fault.
> >
> >I built 0.16.1 this afternoon and the behaviour of svnadmin is identical,
> >and repeatable; always to log.0000000094.
> >
> >Anyone with an idea of what could be going on? Next step? (other than a
> >debug build and running it in gdb, which I'll do next)
> >
> >
> If you have the ability to do so, I'd recompile db in DIAGNOSTIC mode
> and run the process under the debugger. If not a stack trace would
> probably be a good place to start.
First thing to note: building db with --with-debug meant it now gets to
log.0000000106. The stack trace is:
Program received signal SIGSEGV, Segmentation fault.
0xff273de4 in __log_register_recover (dbenv=0x31228, dbtp=0x1a7cf8,
lsnp=0x0,
op=DB_TXN_BACKWARD_ROLL, info=0x19ac18) at ../log/log_rec.c:139
139 __db_err(dbenv,
(gdb) bt
#0 0xff273de4 in __log_register_recover (dbenv=0x31228, dbtp=0x1a7cf8,
lsnp=0x0, op=DB_TXN_BACKWARD_ROLL, info=0x19ac18) at
../log/log_rec.c:139
#1 0xff23b8a0 in __db_dispatch (dbenv=0x31228, dtab=0x0, db=0xffbef5c0,
lsnp=0xffbef598, redo=DB_TXN_BACKWARD_ROLL, info=0x19ac18)
at ../db/db_dispatch.c:202
#2 0xff250ecc in __db_apprec (dbenv=0x31228, max_lsn=0x0, flags=4290704832)
at ../env/env_recover.c:385
#3 0xff24ec1c in __dbenv_open (dbenv=0x31228,
db_home=0x2db70 "/usr/local/apache2/htdocs/ARMTechWin/db", flags=161825,
mode=438) at ../env/env_open.c:288
#4 0xff340a9c in svn_fs_berkeley_recover (
path=0x2d900 "/usr/local/apache2/htdocs/ARMTechWin/db", pool=0x2d230)
at subversion/libsvn_fs/fs.c:637
#5 0xff38fe84 in svn_repos_recover (
path=0x2b430 "/usr/local/apache2/htdocs/ARMTechWin", pool=0x2b228)
at subversion/libsvn_repos/repos.c:1003
#6 0x120d8 in subcommand_recover (os=0x2b350, baton=0xffbefb68,
pool=0x2b228)
Line 139 is:
139 __db_err(dbenv,
140 "Improper file close. LSN: %lu/%lu.",
141 (u_long)lsnp->file, (u_long)lsnp->of
and lsnp is NULL (as per stack trace). So it seems that lsnp is being
cleared in db_dispatch()
Two questions from this:
1) Is this now an issue for subversion, or should it be referred to the
Brekeley DB mob? I'm using 4.0.14
2) svnadmin dump stops after revision 106 as well, though without error. I
have my WC, but that means I lose revisions 107-164. In this instance,
nothing to lose sleep over, but not very confidence-inspiring. Any
suggestions on how to recover further?
PJH
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 10 04:41:59 2003