Hello, Can you please kindly consider picking up the fix with revision 1683266 (http://svn.apache.org/viewvc?view=revision&revision=1683266) in the next patch/official subversion release?
It fixes a long standing issue in the subversion Perl bindings, whereby a client stressing the interface can cause a Perl stack corruption/segfault in the Swig wrapper to subversion. The patch fixes, at least, the Swig typemap definition around the “result _digest” argument, so that it is handled in a safe manner: instead of calculating beforehand the Perl stack address where the result of the svn_swig_pl_from_md5() is going to be stored, is rather calculated after the function has been called. The md5 function has the potential to reallocate the Perl stack elsewhere in memory, so any stack addresses calculated before the function call can become invalid after the call. In my use case, I have git calling the subversion perl binding to retrieve the files from a moderately large subversion repository, whereby I am getting consistent segmentation faults at that point where svn_txdelta_apply() is being called: SVN::TxDelta::apply(GLOB(0x60107ece8), GLOB(0x6011ee3a0), undef, SVN::Pool=REF(0x6011ee268)) called at /usr/share/perl5/site_perl/Git/SVN/Fetcher.pm line 368 Git::SVN::Fetcher::apply_textdelta(Git::SVN::Fetcher=HASH(0x6010236a0), HASH(0x6011ee2e0), undef, _p_apr_pool_t=SCALAR(0x60113e510)) called at /usr/lib/perl5/vendor_perl/SVN/Ra.pm line 623 SVN::Ra::Reporter::AUTOLOAD(SVN::Ra::Reporter=ARRAY(0x6010e9ee0), SVN::Pool=REF(0x6010ea228)) called at /usr/share/perl5/site_perl/Git/SVN/Ra.pm line 312 Swig, taking in account the result_digest typemap, generates the following code in the wrapper _wrap_svn_txdelta_apply function at subversion/subversion/bindings/swig/perl/native/svn_delta.c: if (argvi >= items) EXTEND(sp,1); ST(argvi) = svn_swig_pl_from_md5(arg3); argvi++ ; When the available perl stack size happens to be at 24 SV* just before the call on my system (MSYS2 on windows 7), the svn_swig_pl_from_md5 will cause reallocation of the perl stack to a different memory address. The perl stack address calculated beforehand with the ST(argvi) macro will not be valid any more after the call, thus causing a segmentation fault when trying to write the result of the function there. The same fault happens when I try the same job on Arch Linux, thus it is also reproducible across platforms. The fix makes sure that the result of svn_swig_pl_from_md5 is captured in a temporary variable, and stored in ST(argvi) just afterwards: %typemap(argout) unsigned char *result_digest { SV *tmp; PUTBACK; tmp = svn_swig_pl_from_md5($1); SPAGAIN; %append_output(tmp); } I have tested the fix to work in my case. A more detailed analysis of the issue with regards to this particular client can be found at http://www.mail- archive.com/g...@vger.kernel.org/msg97227.html . Thank you, Yannis