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

Re: EDEADLK in svn_repos_fs_begin_txn_for_commit2

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Wed, 26 Jan 2011 13:21:51 +0000

Philip Martin <philip.martin_at_wandisco.com> writes:

> Philip Martin <philip.martin_at_wandisco.com> writes:
>> Create two repositories with a pre-commit hook that sleeps for 20
>> seconds. Start two threaded svnserve processes listening on different
>> ports.
>> svnserve -Tdr.
>> svnserve -Tdr. --listen-port 3691
>> Commit:
>> svn mkdir -mm svn://localhost/repoA/X1
>> svn mkdir -mm svn://localhost:3691/repoB/X1
>> svn mkdir -mm svn://localhost/repoB/X2
>> svn mkdir -mm svn://localhost:3691/repoA/X2
>> All four commits complete. Do I need to cause the thread to spin rather
>> than wait for a hook script?
> That's not right, it just tests commit contention. What I need to do is
> make the server spin while holding the txn-current-lock, that will
> require some temporary code. I still don't see how it can deadlock.

This patch causes the FS code to spin for about 10 seconds (a debug
build on my machine) while holding the lock. The results are not
exactly what I expected.

Index: subversion/libsvn_fs_fs/fs_fs.c
--- subversion/libsvn_fs_fs/fs_fs.c (revision 1063629)
+++ subversion/libsvn_fs_fs/fs_fs.c (working copy)
@@ -583,6 +583,14 @@
       err = body(baton, subpool);
+ if (!strcmp(lock_filename, path_txn_current_lock(fs, pool)))
+ {
+ int i, j, k = 0;
+ for (i = 0; i < 200000; ++i)
+ for (j = 0; j < 10000; ++j)
+ k += j + i;
+ }

I start the four commits above, one after the other with a small delay
between them. The commits run in parallel and they all block, then
after about 10 seconds the first two complete, and then the third fails

svn: Can't get exclusive lock on file '/home/pm/sw/subversion/obj/repoA/db/txn-current-lock': Resource deadlock avoided

Then after a bit more delay the fouth completes.

I didn't expect the failed commit. On the other hand it appears to be
handled gracefully: the server keeps running and the client gets

Received on 2011-01-26 14:22:35 CET

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