Branko ÄŒibej wrote:
> cmpilato@collab.net wrote:
>
>> I just reproduced the FS hangs locally using Philip magnifi-script
>> (dude, you are to be publically praised for that beaut). The hang in
>> the committing svn (the others are stuck updating) occurs here:
>>
>> #0 0x401d217e in __select () from /lib/libc.so.6
>>
>> [... Berkeley stuff ...]
>>
>> #12 0x808c626 in svn_fs__get_txn (txn_skel=0xbffff640,
>> fs=0x80f9140, svn_txn=0x8107930 "385", trail=0x8134ee0)
>> at subversion/libsvn_fs/txn-table.c:225
>> #13 0x808c7d5 in svn_fs__get_txn_ids (root_id_p=0xbffff66c,
>> base_root_id_p=0xbffff668, fs=0x80f9140, svn_txn=0x8107930 "385",
>> trail=0x8134ee0) at subversion/libsvn_fs/txn-table.c:292
>> #14 0x808be8c in txn_body_txn_root (baton=0xbffff6c0, trail=0x8134ee0)
>> at subversion/libsvn_fs/tree.c:2758
>> #15 0x8088592 in svn_fs__retry_txn (fs=0x80f9140,
>> txn_body=0x808be34 <txn_body_txn_root>, baton=0xbffff6c0,
>> pool=0x81348c0) at subversion/libsvn_fs/trail.c:127
>> #16 0x808bf07 in svn_fs_txn_root (root_p=0xbffff6f4, txn=0x8109818,
>> pool=0x81348c0) at subversion/libsvn_fs/tree.c:2778
>> #17 0x808a727 in txn_body_merge (baton=0xbffff768, trail=0x81098e0)
>> at subversion/libsvn_fs/tree.c:1634
>> #18 0x8088592 in svn_fs__retry_txn (fs=0x80f9140,
>> txn_body=0x808a5a8 <txn_body_merge>, baton=0xbffff768, pool=0x8109700)
>> at subversion/libsvn_fs/trail.c:127
>> #19 0x808ab83 in svn_fs_commit_txn (conflict_p=0xbffff7d8,
>> new_rev=0xbffff7e0, txn=0x8109818) at subversion/libsvn_fs/tree.c:1826
>>
>> [... libsvn_repos stuff and so on]
>>
>> Not that we enter through the public FS API twice, once at
>> svn_fs_commit_txn, and once at svn_fs_txn_root.
>>
>> Now, when I was working on turning off deltification of directory
>> entries in the filesystem code last week, I posted to the list my
>> patch and a request for help because with my patch in place, Berkeley
>> would hang in __select(). I determined that the hangs would disappear
>> if I didn't re-enter the public FS API (more specifically, if I didn't
>> try to create a Berkeley transaction from within a Berkeley
>> transaction), my hangs disappeared. The exact same bug (and solution)
>> hit me later last week when I was implementing the recursive tree
>> (un-)deltification.
>>
>> I wonder...could the same thing be happening here?
>>
>
> Let me guess ... the transactions created by the two calls to the
> top-level API are not related in any way -- i.e., one is not a child
> of the other. Therefore they aren't nested. Therefore they can deadlock.
>
> Now why do I get the feeling this can't be right?
>
>
> I think we need a lower-level API that mimics the public one, except
> that every function accepts a trail parameter. Calling any public FS
> api function from within the FS implementation should be absolutely
> prohibited.
>
Funny -- IIRC we already *have* such a shadow API, or most of it at
least ...
--
Brane ÄŒibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:01 2006