Justin Erenkrantz <jerenkrantz@apache.org> writes:
> On Sat, Jul 13, 2002 at 03:40:48PM +0100, Philip Martin wrote:
> > Justin Erenkrantz <jerenkrantz@apache.org> writes:
> >
> > > > 664 svn ci -F log include/svn_wc.h include/svn_error_codes.h
> > > > libsvn_wc/props.c libsvn_client/prop_commands.c
> > > > *** I CTRL-C'd this for some reason before any output.
> > > > 665 cat log
> > > > 666 svn ci -F log include/svn_wc.h include/svn_error_codes.h
> > > > libsvn_wc/props.c libsvn_client/prop_commands.c
> > > > *** This segfaulted, but created a valid new revision.
> > >
> > > The segfault can be reproduced by commiting without anything in . -
> >
> > Can you give me a reproduction recipe? I still can't make it fail.
>
> I just did exactly what Pilchie did in a clean test repository that
> had three subdirectories with files to modify in each folder. You
> do have to hit Ctrl-C before any output. Then, repeat the commit.
That gets fixed by r2504? Do you mean that the set of directories
that get locked is different depending on whether the previous commit
was interrupted? That sounds like a serious problem that should not
be hidden by taking an extra lock. The precommit processing should
always lock the same set of directories.
Ah, I think I see the real problem. Look at harvest_committables in
commit_util.c, it's calling lock_dir without checking the return
value. I think the correct solution is to revert 2504 and wrap
lock_dir in an SVN_ERR. The when you try the second commit you will
get an "already locked" error and need to run cleanup before trying
the commit again.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 13 19:53:28 2002