I took a look at the deadlock which is easy to reproduce using stress.pl
using db-4.1.25 and has been reported a few times with no resolution:
Transmitting file data .svn: Item already exists in filesystem
svn: Commit failed (details follow):
svn: successor id `0.0.x2' (for `0.0.wu') already exists in filesystem
'/var/tmp/svn/repostress/db'
svn: Berkeley DB deadlock error
svn: Berkeley DB error while reading node revision for filesystem
/var/tmp/svn/repostress/db:
DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock
unexpected commit fail: exit status: 256
the problem appears to be simply that the DB_LOCK_DEADLOCK error
returned by svn_fs__bdb_get_node_revision gets wrapped on the error
stack by svn_fs__bdb_new_successor_id, so svn_fs__retry_txn doesn't spot
it and retry appropriately. Or am I being stupidly naive and it's
really a lot more complicated than this?
One way to fix this would be as below - my stress.pl's have got to
revision 400 now with this applied, without it they would reliably die
before getting to 200.
--- subversion-0.22.2/subversion/libsvn_fs/trail.c.trail
+++ subversion-0.22.2/subversion/libsvn_fs/trail.c
@@ -123,7 +123,8 @@
for (;;)
{
trail_t *trail;
- svn_error_t *svn_err;
+ svn_error_t *svn_err, *err;
+ int deadlocked = 0;
SVN_ERR (begin_trail (&trail, fs, pool));
@@ -138,8 +139,13 @@
return SVN_NO_ERROR;
}
- /* Is this a real error, or do we just need to retry? */
- if (svn_err->apr_err != SVN_ERR_FS_BERKELEY_DB_DEADLOCK)
+ /* See whether there's a deadlock error in the error stack. */
+ for (err = svn_err; err; err = err->child)
+ if (err->apr_err == SVN_ERR_FS_BERKELEY_DB_DEADLOCK)
+ deadlocked = 1;
+
+ /* If no deadlock, then this is a real error. */
+ if (!deadlocked)
{
/* Ignore any error returns. The first error is more valuable. */
svn_error_clear (abort_trail (trail, fs));
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 5 20:47:24 2003