James McCoy <jamessan_at_debian.org> writes:
> As reported in Debian[0], using git-svn to clone a Subversion repo will
> reliably crash in Subversion's Perl bindings if there are commits
> touching many files.
>
> [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780246
>
> The original report referenced a private repo, but it was reproduced
> using KDE's svn repo using the following command:
>
> git-svn clone -s 28995:HEAD svn://anonsvn.kde.org/home/kde
-r rather than -s.
I can reproduce that in my dev build using:
LD_LIBRARY_PATH=subversion/bindings/swig/perl/libsvn_swig_perl/.libs:subversion/libsvn_subr/.libs:subversion/libsvn_client/.libs:subversion/libsvn_delta/.libs:subversion/libsvn_repos/.libs:subversion/libsvn_fs/.libs:subversion/libsvn_ra/.libs:subversion/libsvn_wc/.libs:subversion/libsvn_diff/.libs PERL5LIB=subversion/bindings/swig/perl/native/blib/lib:subversion/bindings/swig/perl/native/blib/arch gdb -q -arg perl /usr/lib/git-core/git-svn clone -r 28995:HEAD
svn://anonsvn.kde.org/home/kde repo-git
and I see:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff0316b86 in _wrap_svn_txdelta_apply (my_perl=0x603010, cv=0xfe59e8)
at svn_delta.c:3918
3918 ST(argvi++) = svn_swig_pl_from_md5(arg3);
(gdb)
> This was originally reproduced with 1.8.10 and I see the below error
> from valgrind leading up to the crash (using debugperl from the
> perl-debug package to get symbols):
>
> ==11979== Invalid write of size 8
> ==11979== at 0xC7CEA31: _wrap_svn_txdelta_apply (svn_delta.c:3918)
> ==11979== by 0x4FF9B6: Perl_pp_entersub (pp_hot.c:2794)
> ==11979== by 0x4CA718: Perl_runops_debug (dump.c:2427)
> ==11979== by 0x559D15: S_docatch (pp_ctl.c:3227)
> ==11979== by 0x4CA718: Perl_runops_debug (dump.c:2427)
> ==11979== by 0x43F508: Perl_call_sv (perl.c:2756)
> ==11979== by 0x852B397: svn_swig_pl_callback_thunk (swigutil_pl.c:625)
> ==11979== by 0x852B864: thunk_apply_textdelta (swigutil_pl.c:873)
> ==11979== by 0xE15034B: ra_svn_handle_apply_textdelta (editorp.c:717)
> ==11979== by 0xE15065D: svn_ra_svn_drive_editor2 (editorp.c:938)
> ==11979== by 0xE14AFBB: ra_svn_finish_report (client.c:299)
> ==11979== by 0x109B183C: svn_ra_reporter2_invoke_finish_report (svn_ra.c:2066)
> ==11979== by 0x109B183C: _wrap_svn_ra_reporter2_invoke_finish_report (svn_ra.c:12746)
> ==11979== Address 0xbb97d20 is 27,936 bytes inside a block of size 27,992 free'd
> ==11979== at 0x4C2AF2E: realloc (vg_replace_malloc.c:692)
> ==11979== by 0x4CCFA5: Perl_safesysrealloc (util.c:244)
> ==11979== by 0x4F0F17: Perl_av_extend_guts (av.c:154)
> ==11979== by 0x555422: Perl_stack_grow (scope.c:38)
> ==11979== by 0x4F5620: Perl_pp_padrange (pp_hot.c:373)
> ==11979== by 0x4CA718: Perl_runops_debug (dump.c:2427)
> ==11979== by 0x43F508: Perl_call_sv (perl.c:2756)
> ==11979== by 0x852B397: svn_swig_pl_callback_thunk (swigutil_pl.c:625)
> ==11979== by 0x852EAEE: svn_swig_pl_from_md5 (swigutil_pl.c:1837)
> ==11979== by 0xC7CEA2C: _wrap_svn_txdelta_apply (svn_delta.c:3918)
> ==11979== by 0x4FF9B6: Perl_pp_entersub (pp_hot.c:2794)
> ==11979== by 0x4CA718: Perl_runops_debug (dump.c:2427)
I also see that. Given that Perl has realloc'd some memory I suppose
it might be a reference counting bug in Subversion's XS code.
Or perhaps the bug might be this code in svn_types.swg:
%typemap(argout) unsigned char *result_digest {
/* FIXME: This code is clearly buggy. The return value of sv_newmortal()
is immediately overwritten by the return value
of svn_swig_pl_from_md5(). */
ST(argvi) = sv_newmortal();
ST(argvi++) = svn_swig_pl_from_md5($1);
}
#endif
The real problem is that nobody maintains Subversion's Perl bindings.
We need somebody who understands Perl XS code.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2015-03-18 15:49:43 CET