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

'svnsync_tests.py 23 --fs-type bdb' fails due to process abort

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Wed, 23 Jan 2008 16:02:23 -0500

svnsync_tests.py is failing on test 23 when using a BDB backend because the
svnsync process abort()s. The reason for the abort() is obvious to seasoned
libsvn_fs_base developers, but probably not to others, so I thought I'd
explain it here.

The summary is, "It's really really bad to nest Berkeley DB transactions in
our codebase, so we have logic to abort() when someone tries to do so."

In practice, the rule is, "When you're inside one of those txn_body_*
functions in libsvn_fs_base, you're also inside a BDB transaction. This
means you really shouldn't make any calls to public FS functions because
their implementations might try to do something BDB-transaction-y, which
would cause a BDB transaction nesting attempt, and thus will trigger our
abort() check."

Specifically in this case, svn_fs_base__dag_commit_txn() (which is wrapped
with a BDB transaction) calls svn_fs_mergeinfo__update_index(), which in
turn calls index_txn_mergeinfo(), which calls (UH-OH!) svn_fs_revision_root().

I started to fix this weeks ago on the reintegrate branch, but stopped
because that branch took a turn towards removing sqlite from BDB altogether.
     I was under the impression that this task had been completed (hence my
commit of r29004 this morning), since I was told yesterday that the
reintegrate branch had been merged into trunk. Clearly, the branch was
merged *without* that sqlite purge having been completed, which means that
my r29004 change is flatly wrong, and that our trunk codebase contains
illegal call sequences at commit finalization time which will trigger abort()s.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2008-01-23 22:02:40 CET

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.