Kevin Pilch-Bisson <kevin@pilch-bisson.net> writes:
Didn't see this when I commented on issue 792.
> Okay I'm home, and I have some more info to pass along.
>
> 1. I actually had 2 segfaults after commits today. The first one didn't
> seem to have an affect on the commit.
>
> 2. My guess is that the first segfault is the cause of the problem, exactly
> as Ben described elsewhere. entries file thinks its at the new rev, but
> text-base isn't.
>
> 3. For reference, here is part of my 'history' output with commentary.
>
> 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.
This locked the libsvn_wc directory which is at rev 2471. The lock
file is timed about 20 minutes before rev 2485. Interrupting means
that the lock didn't get cleared.
> 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 existing lock prevented the client locking libsvn_wc but that
failure was ignored. Revision 2485 was created on the server. The
client attempted to use the missing lock and segfaulted. Thus the
working copy remains at rev 2471 and libsvn_wc/props.c remains in
state M. The segfault didn't occur until after include/ had been
updated, so in the working copy svn_wc.h and svn_error_codes.h change
to rev 2485.
> 667 ls
> 668 gdb core
> *** I had ulimit -c set to zero.
> 669 ls
> 670 svn ci -F log include/svn_wc.h include/svn_error_codes.h
> libsvn_wc/props.c libsvn_client/prop_commands.c
> *** This did nothing, because svn thought I had finished the commit.
Odd. I would have expected it to try the commit again,
libsvn_wc/props.c and libsvn_client/prop_commands.c are still in state
M. It would not send svn_wc.h or svn_error_codes.h because they are
at rev 2485 and are not modified, but it would send props.c. I would
expect the server to give either a merge error or a transaction out of
date error. The client would once again fail to lock libsvn_wc
because the original lock remains, but would ignore the problem.
Since the server rejects the commit the client will not
attemptpost-commit processing and will not segfault.
> 671 cd clients/cmdline/
> 672 vi main.c
> 673 cd ../
> 674 cd ..
> 675 vi libsvn_wc/props.c
> 676 vi libsvn_client/prop_commands.c
> 677 vi log
> 678 vi log
> 679 svn ci -F log clients/cmdline/main.c libsvn_wc/props.c
> *** I CTRL-C'd this to set ulimit in case it segfaulted again.
If not interrupted I would have expected this to try to commit
libsvn_wc/props.c and for the server to reject it.
> 680 man ulimit
> 681 man 1 ulimit
> 682 man 2 ulimit
> 683 man 4 ulimit
> 684 man 5 ulimit
> 685 man 6 ulimit
> 686 man 7 ulimit
> 687 man 8 ulimit
> *** Me trying to figure out how to set ulimit (and not finding a manpage).
> 688 ulimit -a
> 689 ulimit -c unlimited
> *** Me guessing
> 690 ulimit -a
> 691 svn ci -F log clients/cmdline/main.c libsvn_wc/props.c
> *** This is the bogus commit
I would have expected this to try to commit libsvn_wc/props.c and for
the server to reject it. The working copy is still rev 2471 and yet
rev 2485 exists on the server. Somehow it succeeds?!? It then
segfaults in the post-commit processing because it failed to lock
libsvn_wc, but ignored the error and then tried to use the missing
lock.
Looking at the tar file, props.c is at rev 2471, and the text-base is
correct for that revision. So why didn't the server reject the
commit?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 15 18:07:21 2002