{"thread":{"id":"34463","subject":"git svn fetch segfault on exit","startedAt":"2013-07-18T09:21:06Z","lastAt":"2013-09-02T13:05:50Z","messageCount":5,"participants":["Jonathan Lambrechts","Thomas Rast","uli","Evgeny Kotkov","Uli Heller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"223638","messageId":"51E7B382.8050302@gmail.com","threadId":"34463","inReplyTo":null,"subject":"git svn fetch segfault on exit","fromName":"Jonathan Lambrechts","fromEmail":"jonathanlambrechts@gmail.com","sentAt":"2013-07-18T09:21:06Z","receivedAt":"2013-07-18T09:21:06Z","isPatch":false,"sender":{"key":"jonathanlambrechts@gmail.com","avatar":null},"body":"Hi,\nI'm using archlinux with git version 1.8.3.3, svn version 1.8.0 \n(r1490375) and perl v5.18.0 (built for x86_64-linux-thread-multi)\n\nEvery git svn call that involves a fetch produces a segmentation fault \non exit (but the operation succeeds).\n\n*** Error in `/usr/bin/perl': double free or corruption (!prev): \n0x0000000002ce1ac0 ***\n======= Backtrace: =========\n/usr/lib/libc.so.6(+0x788ae)[0x7fd4d83798ae]\n/usr/lib/libc.so.6(+0x79587)[0x7fd4d837a587]\n/usr/lib/libapr-1.so.0(apr_allocator_destroy+0x1d)[0x7fd4d568e9ad]\n/usr/lib/libapr-1.so.0(apr_pool_terminate+0x30)[0x7fd4d568f590]\n/usr/lib/perl5/vendor_perl/auto/SVN/_Core/_Core.so(_wrap_apr_terminate+0x50)[0x7fd4d6886920]\n/usr/lib/perl5/core_perl/CORE/libperl.so(Perl_pp_entersub+0x571)[0x7fd4d876f821]\n/usr/lib/perl5/core_perl/CORE/libperl.so(Perl_runops_standard+0x16)[0x7fd4d8767e26]\n/usr/lib/perl5/core_perl/CORE/libperl.so(Perl_call_sv+0x3b0)[0x7fd4d86f93b0]\n/usr/lib/perl5/core_perl/CORE/libperl.so(Perl_call_list+0x2c7)[0x7fd4d86fb477]\n/usr/lib/perl5/core_perl/CORE/libperl.so(perl_destruct+0x1321)[0x7fd4d86fca91]\n/usr/bin/perl(main+0x111)[0x400e01]\n/usr/lib/libc.so.6(__libc_start_main+0xf5)[0x7fd4d8322a15]\n/usr/bin/perl[0x400e71]\n\nThis bug has already been reported by others on subversion mailing list \nand and archlinux bbs:\nhttps://bugs.archlinux.org/task/36070\nhttp://permalink.gmane.org/gmane.comp.version-control.subversion.user/114019\n\nI tried to fix it but the problem is that I know absolutely nothing of \nperl. Anyway, I noticed that with the modifications bellow (in \nGit::SVN::Ra::new) the crash does not occur (I do not think it's a real \nfix though).\n\n--- /usr/share/perl5/vendor_perl/Git/SVN/Ra.pm.orig    2013-07-18 \n11:15:23.584625508 +0200\n+++ /usr/share/perl5/vendor_perl/Git/SVN/Ra.pm    2013-07-18 \n11:16:14.624622422 +0200\n@@ -79,7 +79,6 @@\n      SVN::_Core::svn_config_ensure($config_dir, undef);\n      my ($baton, $callbacks) = \nSVN::Core::auth_open_helper(_auth_providers);\n      my $config = SVN::Core::config_get_config($config_dir);\n-    $RA = undef;\n      my $dont_store_passwords = 1;\n      my $conf_t = ${$config}{'config'};\n      {\n@@ -108,7 +107,7 @@\n                            config => $config,\n                    pool => SVN::Pool->new,\n                            auth_provider_callbacks => $callbacks);\n-    $RA = bless $self, $class;\n+    $self = bless $self, $class;\n\n      # Make sure its canonicalized\n      $self->url($url);\n@@ -118,7 +117,7 @@\n      $self->{cache} = { check_path => { r => 0, data => {} },\n                         get_dir => { r => 0, data => {} } };\n\n-    return $RA;\n+    return $self;\n  }\n\n  sub url {\n\n\nJonathan\n"},{"id":"223642","messageId":"878v146ozb.fsf@linux-k42r.v.cablecom.net","threadId":"34463","inReplyTo":"51E7B382.8050302@gmail.com","subject":"Re: git svn fetch segfault on exit","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-07-18T12:18:16Z","receivedAt":"2013-07-18T12:18:16Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jonathan Lambrechts <jonathanlambrechts@gmail.com> writes:\n\n> Every git svn call that involves a fetch produces a segmentation fault\n> on exit (but the operation succeeds).\n>\n> *** Error in `/usr/bin/perl': double free or corruption (!prev):\n> 0x0000000002ce1ac0 ***\n> ======= Backtrace: =========\n> /usr/lib/libc.so.6(+0x788ae)[0x7fd4d83798ae]\n> /usr/lib/libc.so.6(+0x79587)[0x7fd4d837a587]\n> /usr/lib/libapr-1.so.0(apr_allocator_destroy+0x1d)[0x7fd4d568e9ad]\n> /usr/lib/libapr-1.so.0(apr_pool_terminate+0x30)[0x7fd4d568f590]\n> /usr/lib/perl5/vendor_perl/auto/SVN/_Core/_Core.so(_wrap_apr_terminate+0x50)[0x7fd4d6886920]\n> /usr/lib/perl5/core_perl/CORE/libperl.so(Perl_pp_entersub+0x571)[0x7fd4d876f821]\n> /usr/lib/perl5/core_perl/CORE/libperl.so(Perl_runops_standard+0x16)[0x7fd4d8767e26]\n> /usr/lib/perl5/core_perl/CORE/libperl.so(Perl_call_sv+0x3b0)[0x7fd4d86f93b0]\n> /usr/lib/perl5/core_perl/CORE/libperl.so(Perl_call_list+0x2c7)[0x7fd4d86fb477]\n> /usr/lib/perl5/core_perl/CORE/libperl.so(perl_destruct+0x1321)[0x7fd4d86fca91]\n> /usr/bin/perl(main+0x111)[0x400e01]\n> /usr/lib/libc.so.6(__libc_start_main+0xf5)[0x7fd4d8322a15]\n> /usr/bin/perl[0x400e71]\n\nCan you check if your version of the perl subversion bindings were\ncompiled against the perl and subversion versions that you have\ninstalled?\n\nPerl -- as an interpreted language -- is mostly supposed to be safe from\nsuch segfaults, and since git-svn is pure perl, the likely culprit is in\nthe bindings or the svn libraries.  And the easiest way to get that to\nbreak is a version mismatch.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"226525","messageId":"1378107616368-7595155.post@n2.nabble.com","threadId":"34463","inReplyTo":"51E7B382.8050302@gmail.com","subject":"Re: git svn fetch segfault on exit","fromName":"uli","fromEmail":"uli.heller@daemons-point.com","sentAt":"2013-09-02T07:40:16Z","receivedAt":"2013-09-02T07:40:16Z","isPatch":false,"sender":{"key":"uli.heller@daemons-point.com","avatar":"https://avatars.githubusercontent.com/u/1677414?v=4"},"body":"I'm facing the same issue. I'm using git-1.8.4 and subversion 1.8.3 on\nUbuntu.\n\nI'm proposing a different modification to Ra.pm:\n\n\n\nJonathan's modifications basically disable the use of $RA. The modifications\nabove ensure that the destructor of $RA is called before doing an\napr_terminate().\n\nBest regards, Uli.\n\n\n\n--\nView this message in context: http://git.661346.n2.nabble.com/git-svn-fetch-segfault-on-exit-tp7592205p7595155.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"226530","messageId":"CAPWhs-6E_9T61uf20YKXzwE2j8Tq-sOU9BUw_dVVe=LAH69_iw@mail.gmail.com","threadId":"34463","inReplyTo":"51E7B382.8050302@gmail.com","subject":"Re: git svn fetch segfault on exit","fromName":"Evgeny Kotkov","fromEmail":"evgeny.kotkov@gmail.com","sentAt":"2013-09-02T11:57:33Z","receivedAt":"2013-09-02T11:57:33Z","isPatch":false,"sender":{"key":"evgeny.kotkov@gmail.com","avatar":null},"body":"> Every git svn call that involves a fetch produces a segmentation fault on\n> exit (but the operation succeeds).\n\n>From what I see, this looks quite similiar to the 'serf' issue I've recently\nreported to the serf-dev mailing list [1].  It should be fixed by now, so,\nthe latest serf@trunk build should work fine.\n\n[1]: https://groups.google.com/d/msg/serf-dev/gOn9HTUN98U/pz0_AqdrmJYJ\n\n\nRegards,\nEvgeny Kotkov\n"},{"id":"226531","messageId":"52248D2E.4090206@daemons-point.com","threadId":"34463","inReplyTo":"CAPWhs-6E_9T61uf20YKXzwE2j8Tq-sOU9BUw_dVVe=LAH69_iw@mail.gmail.com","subject":"Re: git svn fetch segfault on exit","fromName":"Uli Heller","fromEmail":"uli.heller@daemons-point.com","sentAt":"2013-09-02T13:05:50Z","receivedAt":"2013-09-02T13:05:50Z","isPatch":false,"sender":{"key":"uli.heller@daemons-point.com","avatar":"https://avatars.githubusercontent.com/u/1677414?v=4"},"body":"Am 02.09.2013 13:57, schrieb Evgeny Kotkov:\n>> Every git svn call that involves a fetch produces a segmentation fault on\n>> exit (but the operation succeeds).\n>  From what I see, this looks quite similiar to the 'serf' issue I've recently\n> reported to the serf-dev mailing list [1].  It should be fixed by now, so,\n> the latest serf@trunk build should work fine.\n>\n> [1]: https://groups.google.com/d/msg/serf-dev/gOn9HTUN98U/pz0_AqdrmJYJ\n>\n>\n\nI've tried the patch for 'serf' included in the thread mentioned above \nand I can confirm that it fixes the issue for me.\nThanks Evgeny!\n\nBest regards, Uli.\n"}]}