Re: Segfault in Perl bindings when commit touches a large number of files

On Wed, May 20, 2015 at 10:12 AM, Roderich Schupp <roderich.schupp_at_gmail.com
> wrote:

> Looking at your patch, the offending line may very well be the cause of
> the crash:

Nope, I'll take that back. When this line

    ST(argvi) = sv_newmortal();

is called argvi is still 0, so it is safe. This line is actually how Swig
wraps C functions
returning void. The code produced looks like this:

int argvi = 0;
...
/* handle input parameters, call the C function */
...
/* push return value onto Perl stack */
ST(argvi) = sv_newmortal();

/* push output parameters (if any) onto Perl stack, increment argvi
accordingly */
...

XSRETURN(argvi);

This is a little bit silly: if there are output parameters, the first one
will overwrite ST(0);
otherwise ST(0) will be discarded, since XSRETURN(0) is called at the end.
So, it's useless, but also harmless.

My prime suspects are parameters result_digest and (to a lesser extent)
error_info
of svn_txdelta_apply. These have totally weird behaviour even on the C side.
Both pass an address into svn_txdelta_apply that will be used long after
svn_txdelta_apply
has returned, apparently by the handler function (and baton) that are out
parameters.
The address error_info points to is probably only going to be read, but the
address result_digest points to will be written to. The latter gets special
treatment
in the Perl wrapper that I don't yet understand.

As a simple experiment, I modified the Swig generated svn_delta.c to
effectively
ignore result_digest (AFAICT that's the same approach taken by the Python
bindings):

- always pass NULL for result_digest in the actual call to svn_txdelta_apply
- always return undef as the first value from the Perl wrapper (it's
ignored by git-svn anyway)

et voilà: git svn clone -r 28995:HEAD svn://anonsvn.kde.org/home/kde
has been humming along for more than an hour now.

Cheers, Roderich
Received on 2015-05-21 16:06:26 CEST