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

Re: svn commit: rev 5194 - trunk/subversion/libsvn_fs

From: <cmpilato_at_collab.net>
Date: 2003-03-04 05:52:01 CET

Karl Fogel <kfogel@newton.ch.collab.net> writes:

> I ran five stress.pl's with 5194 subtracted, and got one instance of
> the famous error:
>
> Committing:
> Sending wcstress.24092/trunk/bar1/foo1
> Sending wcstress.24092/trunk/bar2/foo1
> Sending wcstress.24092/trunk/bar2/foo2
> Sending wcstress.24092/trunk/foo2
> Transmitting file data .subversion/libsvn_client/commit.c:670: \
> (apr_err=160020)
> svn: Item already exists in filesystem
> svn: Commit failed (details follow):
> subversion/libsvn_fs/bdb/nodes-table.c:146: (apr_err=160020)
> svn: successor id `0.0.1z3' (for `0.0.1ym') already exists \
> in filesystem '/home/kfogel/src/stress/repostress/db'
> subversion/libsvn_fs/bdb/bdb-err.c:61: (apr_err=160030)
> svn: Berkeley DB deadlock error
> svn: Berkeley DB error while reading node revision for \
> filesystem /home/kfogel/src/stress/repostress/db:
> DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock
> unexpected commit fail: exit status: 256

That's bad. As far as filesystem logic goes, this error can only
happen when two processes have called svn_fs__dag_clone_root() with
the same transaction id. Now, I have no idea how that can happen --
allocate_txn_id() increments ...

Oh wait.

I wonder if this is another retry_txn() kinda thing, where someone is
using stale information that was invalidated by a Berkeley txn that
needed to be retried. Hm...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 4 05:53:35 2003

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.