Re: EDEADLK in svn_repos_fs_begin_txn_for_commit2

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;
+ }
+
   svn_pool_destroy(subpool);
 
 #if SVN_FS_FS__USE_LOCK_MUTEX

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
with:

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
notified.

-- 
Philip