Greg Stein <gstein@lyra.org> writes:
> On Mon, Jun 11, 2001 at 08:45:29PM -0500, Ben Collins-Sussman wrote:
> > sussman@tigris.org writes:
> >
> > > Modified: subversion/libsvn_repos commit_editor.c
> > > Log:
> > > Bugfix for #388: If the client wants to bail during a commit, tell the
> > > RA layer about it (...so it can call svn_fs_abort_txn().)
> >
> > I haven't closed issue 388 yet, because there's still a bug somewhere.
> >
> > Indeed, whenever svn_wc_crawl_local_mods returns an error,
> > libsvn_client calls ra->abort_commit(). But abort_commit() is
> > segfaulting, and I'm trying to debug through this now. It seems that
> > the fs and txn objects are both pseudo-corrupt (?!), which is causing
> > a segfault deep within svn_fs_abort_txn.
>
> Possibly a pool getting tossed? Turn on some of the pool debugging flags in
> apr/lib/apr_pools.c. I believe one of the options will end up zeroing out
> memory when it gets freed. Then if you observe that in the core dump, you'll
> have an indication of a pool problem.
Nope, the bug was more stupid than that. It turns out that the txn I
was fetching from the commit edit-baton was bogus because I was trying
to pull it out of a *composed* edit-baton. I had forgotten that the
edit-baton was composed. :)
But's totally irrelevant now; I just reverted the whole change and
solved the problem in a much better way. Instead of a new
RA->abort_commit() routine, we now have a new editor->abort_edit()
routine. The first solution was badly violating the "opaquenss" rule
of edit-batons. It makes no sense to have one particular editor just
happen to partially-expose the contents of its edit-baton. Instead,
if you want to abort an edit, tell the editor!
See my latest commit.
---------------------------------------------------------------------
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:36:31 2006