On Wed, May 20, 2015 at 10:12 AM, Roderich Schupp <roderich.schupp@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 */


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