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

Re: Wedged repositories [#6251]

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2002-07-23 23:29:46 CEST

Jim Blandy <jimb@red-bean.com> writes:

> Keith Bostic <bostic@sleepycat.com> writes:
> > > Anyhow, I'm CC'ing in Keith Bostic (Hi Keith, hope you don't mind),
> > > hoping he can shed some light on this*.
> > >
> > > Keith: for the record, one of my repositories locked up one day.
> > > First I tried to run 'dbrecover -v -h ${REPOS}/db'. This didn't
> > > unlock my repos. Then I tried 'dbrecover -ve -h ${REPOS}/db' and
> > > it did unlock my repos. Any ideas?
> >
> > The two calls to db_recover shouldn't make any difference with
> > respect to unlocking your repository.
> >
> > We've been tracking this question as Support Request #6251.
> >
> > I think we need to first understand why the repository is locking
> > up. How often does it happen? Can you make it happen at will?
>
> I think both times happened when I called Subversion from Emacs, and
> interrupted the operation.

Were you were using ra_local?

It's quite easy to provoke a lockup by interrupting, or killing, the
stress.pl script running over ra_local. It doesn't surprise me, I've
always assumed that interupting an svn client that is using ra_local
risks locking the database. I assume the client doesn't get a chance
to release its db locks when it's killed. That's why I added the
"stop file" mechanism to stress.pl, it provides a clean way to
interrupt the script.

Here's one such hang doing 'svn st -u'

(gdb) bt
#0 0x403de7ce in select () from /lib/libc.so.6
#1 0x4018ebfc in __DTOR_END__ () from /usr/local/db4/debug/lib/libdb-4.0.so
#2 0x40169592 in __os_yield (dbenv=0x0, usecs=1000000)
    at ../dist/../os/os_spin.c:109
#3 0x400e7228 in __db_tas_mutex_lock (dbenv=0x808de10, mutexp=0x405f9bf8)
    at ../dist/../mutex/mut_tas.c:151
#4 0x4014fe2a in __lock_get_internal (lt=0x808e1f0, locker=2147484939,
    flags=0, obj=0x80919a4, lock_mode=DB_LOCK_READ, timeout=0, lock=0xbffff3b0)
    at ../dist/../lock/lock.c:827
#5 0x4014f004 in __lock_get (dbenv=0x808de10, locker=2147484939, flags=0,
    obj=0x80919a4, lock_mode=DB_LOCK_READ, lock=0xbffff3b0)
    at ../dist/../lock/lock.c:514
#6 0x4011fb0c in __db_lget (dbc=0x8091938, action=0, pgno=1,
    mode=DB_LOCK_READ, lkflags=0, lockp=0xbffff3b0)
    at ../dist/../db/db_meta.c:367
#7 0x400f8604 in __bam_search (dbc=0x8091938, root_pgno=0, key=0xbffff614,
    flags=1409, stop=1, recnop=0x0, exactp=0xbffff4d4)
    at ../dist/../btree/bt_search.c:118
#8 0x400edd98 in __bam_c_search (dbc=0x8091938, root_pgno=0, key=0xbffff614,
    flags=32, exactp=0xbffff4d4) at ../dist/../btree/bt_cursor.c:2509
#9 0x400ea526 in __bam_c_get (dbc=0x8091938, key=0xbffff614, data=0xbffff5fc,
    flags=32, pgnop=0xbffff54c) at ../dist/../btree/bt_cursor.c:967
#10 0x40115b7b in __db_c_get (dbc_arg=0x8091938, key=0xbffff614,
    data=0xbffff5fc, flags=32) at ../dist/../db/db_cam.c:704
#11 0x4010e52d in __db_get (dbp=0x8091620, txn=0x8094df0, key=0xbffff614,
    data=0xbffff5fc, flags=32) at ../dist/../db/db_am.c:481
#12 0x40071878 in svn_fs__get_txn (txn_p=0xbffff654, fs=0x808dd30,
    txn_name=0x8094ed0 "l", trail=0x80889a8)
    at ../svn/subversion/libsvn_fs/bdb/txn-table.c:192
#13 0x4007a25d in get_rev_txn (txn_p=0xbffff698, txn_id=0x0, fs=0x808dd30,
    rev=6, trail=0x80889a8) at ../svn/subversion/libsvn_fs/revs-txns.c:49
#14 0x4007a2fa in svn_fs__rev_get_root (root_id_p=0xbffff6d4, fs=0x808dd30,
    rev=6, trail=0x80889a8) at ../svn/subversion/libsvn_fs/revs-txns.c:69
#15 0x40080e00 in txn_body_begin_txn (baton=0xbffff74c, trail=0x80889a8)
    at ../svn/subversion/libsvn_fs/txn.c:108

Following such a lockup if I run 'db_recover -e' I can use the
repository again. However if I run db_recover without the -e option
the repository is useless

$ db_recover -v -h repostress/db
db_recover: Finding last valid log LSN: file: 1 offset 464913
db_recover: Checkpoint at: [1][442965]
db_recover: Checkpoint LSN: [1][442965]
db_recover: Previous checkpoint: [1][441325]
db_recover: Checkpoint at: [1][441325]
db_recover: Checkpoint LSN: [1][441325]
db_recover: Previous checkpoint: [1][427899]
db_recover: Recovery starting from [1][441325]
db_recover: Recovery complete at Tue Jul 23 22:05:17 2002
db_recover: Maximum transaction ID 80000774 Recovery checkpoint [1][465533]
db_recover: Recovery complete at Tue Jul 23 22:05:17 2002
db_recover: Maximum transaction id 80000000 Recovery checkpoint [1][465533]
$ svn co file:///home/pm/repostress wc2

../svn/subversion/libsvn_ra_local/ra_plugin.c:222
svn_error: #21101 : <Couldn't find a repository.>
  Unable to open an ra_local session to URL

../svn/subversion/libsvn_ra_local/split_url.c:129
svn_error: #21101 : <Couldn't find a repository.>
  svn_ra_local__split_URL: Unable to find valid repository

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 23 23:30:26 2002

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

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