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

[PATCH] deadlock fix?

From: Joe Orton <jorton_at_redhat.com>
Date: 2003-06-05 20:46:26 CEST

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
svn: Berkeley DB deadlock error
svn: Berkeley DB error while reading node revision for filesystem
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

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.