{"thread":{"id":"7700","subject":"Segmentation fault in git-svn","startedAt":"2007-04-16T22:17:55Z","lastAt":"2007-05-14T09:02:41Z","messageCount":12,"participants":["Steven Grimm","Eric Wong","Peter Baumann"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"39576","messageId":"4623F613.5010108@midwinter.com","threadId":"7700","inReplyTo":null,"subject":"Segmentation fault in git-svn","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-04-16T22:17:55Z","receivedAt":"2007-04-16T22:17:55Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"I expect this is really a libsvn bug, but git-svn triggers it, so I'm \nhoping someone else has run into and solved it, or at least that someone \ncan reproduce it.\n\nIf I try to clone the \"memcached\" public repository with the command line\n\n  git-svn clone --branches=branches --trunk=trunk \nhttp://code.sixapart.com/svn/memcached\n\nit cranks along fine until revision 299, then dies with SIGSEGV. If I \nrun it again, it appears to pick up where it left off, then dies again \nat revision 399, then again at revision 499. (There are fewer than 600 \nrevisions in that repo so it's anyone's guess if it'd die at 599 given \nthe chance.)\n\nThis happens on both a Linux box (amd64, FC4, svn version 1.4.3) and my \nMac (Intel OS 10.4, svn version 1.2.3 from Fink), so at the very least \nit's not platform-specific. It also happens periodically on the private \nsvn repository at my company, though not as predictably. On my Mac, I'm \nusing the very latest git code from \"master\".\n\nI ran the Perl interpreter under gdb to get a stack trace:\n\n#0  get_private (hk=0x8050300000001, id=0x2aaaaf187b2b \"SVN\") at \nne_request.c:273\n#1  0x00002aaaaf186983 in parsed_request (sess=0xfbc0e0, \nmethod=0x2aaaaf188e19 \"PROPFIND\", url=0x11e5ab0 \"/svn/memcached\",\n    body=0x100ce00 \"<?xml version=\\\"1.0\\\" encoding=\\\"utf-8\\\"?><propfind \nxmlns=\\\"DAV:\\\"><prop><version-controlled-configuration \nxmlns=\\\"DAV:\\\"/><resourcetype xmlns=\\\"DAV:\\\"/><baseline-relative-path \nxmlns=\\\"http://subversion.tigris.o\"..., body_file=0x0, \nset_parser=0x2aaaaf1816e0 <set_parser>, elements=0x2aaaaf28c9e0, \nuse_neon_shim=1, validate_compat_cb=0x2aaaaf1811b0 <validate_element>,\n    startelm_compat_cb=0x2aaaaf181290 <start_element>, \nendelm_compat_cb=0x2aaaaf181400 <end_element>, startelm_cb=0, \ncdata_cb=0, endelm_cb=0, baton=0x7fffff84f630, extra_headers=0x11e5ac0,\n    status_code=0x0, spool_response=0, pool=0x11e5788) at \nsubversion/libsvn_ra_dav/util.c:602\n#2  0x00002aaaaf187228 in svn_ra_dav__parsed_request_compat \n(sess=Variable \"sess\" is not available.\n) at subversion/libsvn_ra_dav/util.c:876\n#3  0x00002aaaaf1818b8 in svn_ra_dav__get_props (results=0x7fffff84f6d0, \nsess=0xfbc0e0, url=0x11e5ab0 \"/svn/memcached\", depth=Variable \"depth\" is \nnot available.\n) at subversion/libsvn_ra_dav/props.c:531\n#4  0x00002aaaaf1819b6 in svn_ra_dav__get_props_resource \n(rsrc=0x7fffff84f7e8, sess=0xfbc0e0, url=0x11e5a80 \"/svn/memcached\", \nlabel=0x0, which_props=0x2aaaaf28c940, pool=0x11e5788)\n    at subversion/libsvn_ra_dav/props.c:558\n#5  0x00002aaaaf181c16 in svn_ra_dav__search_for_starting_props \n(rsrc=0x7fffff84f7e8, missing_path=0x7fffff84f7e0, sess=0xfbc0e0, \nurl=0xfaefd8 \"http://code.sixapart.com/svn/memcached\",\n    pool=0x11e5788) at subversion/libsvn_ra_dav/props.c:667\n#6  0x00002aaaaf181e85 in svn_ra_dav__get_baseline_props \n(bc_relative=0x7fffff84f850, bln_rsrc=0x7fffff84f868, sess=0xfbc0e0, \nurl=Variable \"url\" is not available.\n) at subversion/libsvn_ra_dav/props.c:775\n#7  0x00002aaaaf1824a3 in svn_ra_dav__get_baseline_info (is_dir=0x0, \nbc_url=0x7fffff84f990, bc_relative=0x7fffff84f980, latest_rev=0x0, \nsess=0xfbc0e0, url=Variable \"url\" is not available.\n)\n    at subversion/libsvn_ra_dav/props.c:898\n#8  0x00002aaaaf17ffe0 in svn_ra_dav__get_log (session=Variable \n\"session\" is not available.\n) at subversion/libsvn_ra_dav/log.c:430\n#9  0x00002aaaaf4c46fa in _wrap_svn_ra_get_log (my_perl=Variable \n\"my_perl\" is not available.\n) at svn_ra.c:4552\n#10 0x0000003bd9e9b67e in Perl_pp_entersub () from \n/usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/CORE/libperl.so\n#11 0x0000003bd9e7f3cd in Perl_runops_debug () from \n/usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/CORE/libperl.so\n#12 0x0000003bd9e39b49 in perl_run () from \n/usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/CORE/libperl.so\n#13 0x0000000000401a01 in main ()\n\nCan anyone else reproduce this?\n\n-Steve\n"},{"id":"39625","messageId":"20070417093743.GA9222@muzzle","threadId":"7700","inReplyTo":"4623F613.5010108@midwinter.com","subject":"Re: Segmentation fault in git-svn","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-04-17T09:37:43Z","receivedAt":"2007-04-17T09:37:43Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Steven Grimm <koreth@midwinter.com> wrote:\n> I expect this is really a libsvn bug, but git-svn triggers it, so I'm \n> hoping someone else has run into and solved it, or at least that someone \n> can reproduce it.\n\nI've also been working with another user off-list the past few\ndays on tracking down on a segmentation fault in git-svn.\n\n> If I try to clone the \"memcached\" public repository with the command line\n> \n>  git-svn clone --branches=branches --trunk=trunk \n> http://code.sixapart.com/svn/memcached\n\nI just ran this several (6?) times got a segmentation fault once\nwith Junio's master @ f948792990f82a35bf0c98510e7511ef8acb9cd3.\n\nTrying it again with the same file that segfaulted earlier, it was\nsuccessful, spooky...\n\nI also tried some other patches (see replies) which I've been testing to\nfix the other user's problem.\n\n> it cranks along fine until revision 299, then dies with SIGSEGV. If I \n> run it again, it appears to pick up where it left off, then dies again \n> at revision 399, then again at revision 499. (There are fewer than 600 \n> revisions in that repo so it's anyone's guess if it'd die at 599 given \n> the chance.)\n\nI have definitely not seen this pattern before.\n\nHowever, the following clone has been problematic at times\n\ngit svn clone svn://svn.debian.org/svn/pkg-glibc/glibc-package \\\n  -T trunk -b branches -t tags\n\n> This happens on both a Linux box (amd64, FC4, svn version 1.4.3) and my \n> Mac (Intel OS 10.4, svn version 1.2.3 from Fink), so at the very least \n> it's not platform-specific. It also happens periodically on the private \n> svn repository at my company, though not as predictably. On my Mac, I'm \n> using the very latest git code from \"master\".\n\nI'm running x86, Debian Etch, SVN 1.4.2 from Debian Etch or\n1.4.3 from Debian experimental + do_switch patch[1]\n\nThanks for the stack trace.  This is segfaulting at\na different place (expected, being an http:// repo while\nthe other is svn://)\n\n[1] - http://svn.haxx.se/dev/archive-2007-01/0936.shtml\n\n-- \nEric Wong\n"},{"id":"39626","messageId":"20070417094000.GA2778@muzzle","threadId":"7700","inReplyTo":"20070417093743.GA9222@muzzle","subject":"[PATCH (WIP)] git-svn: cache SVN::Ra functions in a more Perl GC-friendly way","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-04-17T09:40:00Z","receivedAt":"2007-04-17T09:40:00Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"The dirent hash objects returned by get_dir() rely on the\ntemporary pool allocated within our wrapper function itself.\nApparently pushing the pool into global storage that was used in\nits creation does not seem to be enough to avoid it from being\ngarbage-collected; so duplicate that into a plain-old nested\nhash...\n\nThis should not cause data from imports to be corrupted, as\nget_dir is only used between the fetching of revisions and not\nthe revision data itself.  The memory usage done during the\nactual data fetches (which is checksummed) only relies on newly\nallocated pools.\n\nAlso, put our caches for get_dir and check_path calls directly\ninto the SVN::Ra object so they auto-expire when it is\ndestroyed.\n\nSince calling rev_proplist repeatedly per-revision is no longer\nneeded in git-svn, we do not cache calls to it.\n\nSigned-off-by: Eric Wong <normalperson@yhbt.net>\n---\n git-svn.perl |   68 +++++++++++++++++++++++++++++++++++----------------------\n 1 files changed, 42 insertions(+), 26 deletions(-)\n\ndiff --git a/git-svn.perl b/git-svn.perl\nindex 7ebd07b..eb3b79c 100755\n--- a/git-svn.perl\n+++ b/git-svn.perl\n@@ -1360,7 +1360,7 @@ sub traverse_ignore {\n \t\t}\n \t}\n \tforeach (sort keys %$dirent) {\n-\t\tnext if $dirent->{$_}->kind != $SVN::Node::dir;\n+\t\tnext if $dirent->{$_}->{kind} != $SVN::Node::dir;\n \t\t$self->traverse_ignore($fh, \"$path/$_\", $r);\n \t}\n }\n@@ -2855,7 +2855,7 @@ my ($can_do_switch, %ignored_err, $RA);\n BEGIN {\n \t# enforce temporary pool usage for some simple functions\n \tmy $e;\n-\tforeach (qw/get_latest_revnum get_uuid get_repos_root/) {\n+\tforeach (qw/rev_proplist get_latest_revnum get_uuid get_repos_root/) {\n \t\t$e .= \"sub $_ {\n \t\t\tmy \\$self = shift;\n \t\t\tmy \\$pool = SVN::Pool->new;\n@@ -2864,29 +2864,7 @@ BEGIN {\n \t\t\twantarray ? \\@ret : \\$ret[0]; }\\n\";\n \t}\n \n-\t# get_dir needs $pool held in cache for dirents to work,\n-\t# check_path is cacheable and rev_proplist is close enough\n-\t# for our purposes.\n-\tforeach (qw/check_path get_dir rev_proplist/) {\n-\t\t$e .= \"my \\%${_}_cache; my \\$${_}_rev = 0; sub $_ {\n-\t\t\tmy \\$self = shift;\n-\t\t\tmy \\$r = pop;\n-\t\t\tmy \\$k = join(\\\"\\\\0\\\", \\@_);\n-\t\t\tif (my \\$x = \\$${_}_cache{\\$r}->{\\$k}) {\n-\t\t\t\treturn wantarray ? \\@\\$x : \\$x->[0];\n-\t\t\t}\n-\t\t\tmy \\$pool = SVN::Pool->new;\n-\t\t\tmy \\@ret = \\$self->SUPER::$_(\\@_, \\$r, \\$pool);\n-\t\t\tif (\\$r != \\$${_}_rev) {\n-\t\t\t\t\\%${_}_cache = ( pool => [] );\n-\t\t\t\t\\$${_}_rev = \\$r;\n-\t\t\t}\n-\t\t\t\\$${_}_cache{\\$r}->{\\$k} = \\\\\\@ret;\n-\t\t\tpush \\@{\\$${_}_cache{pool}}, \\$pool;\n-\t\t\twantarray ? \\@ret : \\$ret[0]; }\\n\";\n-\t}\n-\t$e .= \"\\n1;\";\n-\teval $e or die $@;\n+\teval \"$e; 1;\" or die $@;\n }\n \n sub new {\n@@ -2919,9 +2897,47 @@ sub new {\n \t$self->{svn_path} = $url;\n \t$self->{repos_root} = $self->get_repos_root;\n \t$self->{svn_path} =~ s#^\\Q$self->{repos_root}\\E(/|$)##;\n+\t$self->{cache} = { check_path => { r => 0, data => {} },\n+\t                   get_dir => { r => 0, data => {} } };\n \t$RA = bless $self, $class;\n }\n \n+sub check_path {\n+\tmy ($self, $path, $r) = @_;\n+\tmy $cache = $self->{cache}->{check_path};\n+\tif ($r == $cache->{r} && exists $cache->{data}->{$path}) {\n+\t\treturn $cache->{data}->{$path};\n+\t}\n+\tmy $pool = SVN::Pool->new;\n+\tmy $t = $self->SUPER::check_path($path, $r, $pool);\n+\t$pool->clear;\n+\tif ($r != $cache->{r}) {\n+\t\t%{$cache->{data}} = ();\n+\t\t$cache->{r} = $r;\n+\t}\n+\t$cache->{data}->{$path} = $t;\n+}\n+\n+sub get_dir {\n+\tmy ($self, $dir, $r) = @_;\n+\tmy $cache = $self->{cache}->{get_dir};\n+\tif ($r == $cache->{r}) {\n+\t\tif (my $x = $cache->{data}->{$dir}) {\n+\t\t\treturn wantarray ? @$x : $x->[0];\n+\t\t}\n+\t}\n+\tmy $pool = SVN::Pool->new;\n+\tmy ($d, undef, $props) = $self->SUPER::get_dir($dir, $r, $pool);\n+\tmy %dirents = map { $_ => { kind => $d->{$_}->kind } } keys %$d;\n+\t$pool->clear;\n+\tif ($r != $cache->{r}) {\n+\t\t%{$cache->{data}} = ();\n+\t\t$cache->{r} = $r;\n+\t}\n+\t$cache->{data}->{$dir} = [ \\%dirents, $r, $props ];\n+\twantarray ? (\\%dirents, $r, $props) : \\%dirents;\n+}\n+\n sub DESTROY {\n \t# do not call the real DESTROY since we store ourselves in $RA\n }\n@@ -3136,7 +3152,7 @@ sub match_globs {\n \t\treturn unless scalar @x == 3;\n \t\tmy $dirents = $x[0];\n \t\tforeach my $de (keys %$dirents) {\n-\t\t\tnext if $dirents->{$de}->kind != $SVN::Node::dir;\n+\t\t\tnext if $dirents->{$de}->{kind} != $SVN::Node::dir;\n \t\t\tmy $p = $g->{path}->full_path($de);\n \t\t\tnext if $exists->{$p};\n \t\t\tnext if (length $g->{path}->{right} &&\n-- \nEric Wong\n"},{"id":"39631","messageId":"20070417095509.GA24800@muzzle","threadId":"7700","inReplyTo":"20070417093743.GA9222@muzzle","subject":"Re: Segmentation fault in git-svn","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-04-17T09:55:09Z","receivedAt":"2007-04-17T09:55:09Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"This disables some pool allocations, forcing it to use the\nglobal one.\n\nOther than that, my eyes are barely open and my brain is\nhaving trouble functioning at this time of morning.\n\ndiff --git a/git-svn.perl b/git-svn.perl\nindex ac44f60..cff81f7 100755\n--- a/git-svn.perl\n+++ b/git-svn.perl\n@@ -2883,7 +2883,7 @@ BEGIN {\n \t\t\twantarray ? \\@ret : \\$ret[0]; }\\n\";\n \t}\n \t$e .= \"\\n1;\";\n-\teval $e or die $@;\n+\t# eval $e or die $@;\n }\n \n sub new {\n@@ -2925,10 +2925,10 @@ sub DESTROY {\n \n sub get_log {\n \tmy ($self, @args) = @_;\n-\tmy $pool = SVN::Pool->new;\n+\t# my $pool = SVN::Pool->new;\n \tsplice(@args, 3, 1) if ($SVN::Core::VERSION le '1.2.0');\n-\tmy $ret = $self->SUPER::get_log(@args, $pool);\n-\t$pool->clear;\n+\tmy $ret = $self->SUPER::get_log(@args);\n+\t# $pool->clear;\n \t$ret;\n }\n \n-- \nEric Wong\n"},{"id":"39752","messageId":"20070418090143.GA11894@muzzle","threadId":"7700","inReplyTo":"20070417095509.GA24800@muzzle","subject":"Re: Segmentation fault in git-svn","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-04-18T09:01:43Z","receivedAt":"2007-04-18T09:01:43Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Eric Wong <normalperson@yhbt.net> wrote:\n> This disables some pool allocations, forcing it to use the\n> global one.\n\nThe verdict is still out on all patches and attempts I've posted\nto fix the segfault.  I'm quite busy at the moment and won't\nbe attending to git-svn things for another few days.\n\n-- \nEric Wong\n"},{"id":"39923","messageId":"20070419213112.GA24780@muzzle","threadId":"7700","inReplyTo":"20070418090143.GA11894@muzzle","subject":"[RFH] Re: Segmentation fault in git-svn","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-04-19T21:31:12Z","receivedAt":"2007-04-19T21:31:12Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Eric Wong <normalperson@yhbt.net> wrote:\n> Eric Wong <normalperson@yhbt.net> wrote:\n> The verdict is still out on all patches and attempts I've posted\n> to fix the segfault.  I'm quite busy at the moment and won't\n> be attending to git-svn things for another few days.\n\nOk, those didn't work.  I'm still preoccupied with another project\nthat has a higher priority; and I've come down with a cold so\nif anybody else wants to step up to the plate, please take a stab\nat it.\n\nThis issue has NOT been known to cause data corruption from any\nusers that experienced it[1].  It seems to be happening\nin between when changesets are actually fetched.\n\n[1] - if there is any corruption to a particular file, it'll\n trigger an MD5 mismatch the next time that file is updated.\n\n-- \nEric Wong\n"},{"id":"40272","messageId":"462D544C.8010206@midwinter.com","threadId":"7700","inReplyTo":"20070417094000.GA2778@muzzle","subject":"Re: [PATCH (WIP)] git-svn: cache SVN::Ra functions in a more Perl GC-friendly way","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-04-24T00:50:20Z","receivedAt":"2007-04-24T00:50:20Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"FYI, with this patch, it actually dies more often. The stack seems to be \ncorrupted so I can't give you a useful stack trace, but here's what gdb \nsays:\n\nProgram received signal EXC_BAD_ACCESS, Could not access memory.\nReason: KERN_PROTECTION_FAILURE at address: 0x00000024\n0x90002fe0 in strcmp ()\n(gdb) where\n#0  0x90002fe0 in strcmp ()\n#1  0x004e2ac6 in get_private ()\nPrevious frame inner to this frame (corrupt stack?)\n\n-Steve\n"},{"id":"40376","messageId":"20070425064053.GA4310@muzzle","threadId":"7700","inReplyTo":"462D544C.8010206@midwinter.com","subject":"Re: [PATCH (WIP)] git-svn: cache SVN::Ra functions in a more Perl GC-friendly way","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-04-25T06:40:53Z","receivedAt":"2007-04-25T06:40:53Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Steven Grimm <koreth@midwinter.com> wrote:\n> FYI, with this patch, it actually dies more often. The stack seems to be \n> corrupted so I can't give you a useful stack trace, but here's what gdb \n> says:\n\nYikes.\n\nThanks for the feedback.  Sorry, I've still been busy with another big\nproject and haven't been able to track down this nasty bug.\n\nIf somebody wants to take a stab at working around it: hack up a patch\nthat forks a new child (reusing the main connection) for every revision\nit needs to fetch.  It should still be as fast as normal on *nix\nmachines because fork() is fast and it won't have to renegotiate the\nconnection in every child, but memory leaks and corruption won't have a\nchance to accumulate.\n\n-- \nEric Wong\n"},{"id":"40957","messageId":"20070503123512.GA6500@xp.machine.xx","threadId":"7700","inReplyTo":"4623F613.5010108@midwinter.com","subject":"Re: Segmentation fault in git-svn","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-05-03T12:35:12Z","receivedAt":"2007-05-03T12:35:12Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Mon, Apr 16, 2007 at 03:17:55PM -0700, Steven Grimm wrote:\n>  I expect this is really a libsvn bug, but git-svn triggers it, so I'm hoping \n>  someone else has run into and solved it, or at least that someone can \n>  reproduce it.\n> \n>  If I try to clone the \"memcached\" public repository with the command line\n> \n>   git-svn clone --branches=branches --trunk=trunk \n>  http://code.sixapart.com/svn/memcached\n> \n>  it cranks along fine until revision 299, then dies with SIGSEGV. If I run it \n>  again, it appears to pick up where it left off, then dies again at revision \n>  399, then again at revision 499. (There are fewer than 600 revisions in that \n>  repo so it's anyone's guess if it'd die at 599 given the chance.)\n> \n>  This happens on both a Linux box (amd64, FC4, svn version 1.4.3) and my Mac \n>  (Intel OS 10.4, svn version 1.2.3 from Fink), so at the very least it's not \n>  platform-specific. It also happens periodically on the private svn \n>  repository at my company, though not as predictably. On my Mac, I'm using \n>  the very latest git code from \"master\".\n> \n\nI'm getting segfaults in git-svn, too.\n\nThis command segfaults reproducably in r55 while running\n\n\tgit svn clone svn://svn.berlios.de/vermont vermont \\\n\t\t-T trunk -b branches -t tags\n\nI recompiled the debian subversion 1.4.3dfsg1-1 with debug support, to get a better\nidea what went wrong.\n\nRelevant output from running this beast under valgrind:\n(full valgrind output available at [1])\n\n[...]\nr54 = f80e8d0ad785cae5a4abfb1fdd04b31167553ab0 (trunk)\n\tD\tcollector/src/testCollector.h\n\tM\tcollector/src/rcvIpfix.h\n\tM\tcollector/src/rcvMessage.c\n\tM\tcollector/src/common.c\n\tM\tcollector/src/rcvIpfix.c\n\tM\tcollector/src/common.h\nr55 = 3fddc1de138e9457385ff43111bcaf6f82884525 (trunk)\n==10403== \n==10403== Invalid read of size 1\n==10403==    at 0x59F90A6: readbuf_getchar (marshal.c:285)\n==10403==    by 0x59F90E6: readbuf_getchar_skip_whitespace (marshal.c:294)\n==10403==    by 0x59FA0F3: svn_ra_svn_read_item (marshal.c:621)\n==10403==    by 0x59FA628: svn_ra_svn_read_tuple (marshal.c:741)\n==10403==    by 0x59FA906: svn_ra_svn_read_cmd_response (marshal.c:799)\n==10403==    by 0x59ED81D: handle_auth_request (client.c:346)\n==10403==    by 0x59F02B1: ra_svn_check_path (client.c:1284)\n==10403==    by 0x59B7FD7: svn_ra_check_path (ra_loader.c:564)\n==10403==    by 0x599DC93: _wrap_svn_ra_check_path (svn_ra.c:6019)\n==10403==    by 0x80BDAD0: Perl_pp_entersub (in /usr/bin/perl)\n==10403==    by 0x80BC3A8: Perl_runops_standard (in /usr/bin/perl)\n==10403==    by 0x8063A1A: perl_run (in /usr/bin/perl)\n==10403==  Address 0x6F6C6720 is not stack'd, malloc'd or (recently) free'd\n==10403== \n==10403== Process terminating with default action of signal 11 (SIGSEGV)\n==10403==  Access not within mapped region at address 0x6F6C6720\n==10403==    at 0x59F90A6: readbuf_getchar (marshal.c:285)\n==10403==    by 0x59F90E6: readbuf_getchar_skip_whitespace (marshal.c:294)\n==10403==    by 0x59FA0F3: svn_ra_svn_read_item (marshal.c:621)\n==10403==    by 0x59FA628: svn_ra_svn_read_tuple (marshal.c:741)\n==10403==    by 0x59FA906: svn_ra_svn_read_cmd_response (marshal.c:799)\n==10403==    by 0x59ED81D: handle_auth_request (client.c:346)\n==10403==    by 0x59F02B1: ra_svn_check_path (client.c:1284)\n==10403==    by 0x59B7FD7: svn_ra_check_path (ra_loader.c:564)\n==10403==    by 0x599DC93: _wrap_svn_ra_check_path (svn_ra.c:6019)\n==10403==    by 0x80BDAD0: Perl_pp_entersub (in /usr/bin/perl)\n==10403==    by 0x80BC3A8: Perl_runops_standard (in /usr/bin/perl)\n==10403==    by 0x8063A1A: perl_run (in /usr/bin/perl)\n==10403== \n==10403== ERROR SUMMARY: 199 errors from 26 contexts (suppressed: 19 from 1)\n==10403== malloc/free: in use at exit: 7,028,898 bytes in 129,440 blocks.\n==10403== malloc/free: 325,184 allocs, 195,744 frees, 21,303,514 bytes allocated.\n==10403== For counts of detected errors, rerun with: -v\n==10403== searching for pointers to 129,440 not-freed blocks.\n==10403== checked 7,214,984 bytes.\n==10403== \n==10403== LEAK SUMMARY:\n==10403==    definitely lost: 4,657 bytes in 118 blocks.\n==10403==      possibly lost: 216 bytes in 13 blocks.\n==10403==    still reachable: 7,024,025 bytes in 129,309 blocks.\n==10403==         suppressed: 0 bytes in 0 blocks.\n==10403== Use --leak-check=full to see details of leaked memory.\n\n===========================================================================\n\nsubversion/libsvn_ra_svn/marshal.c:\n[...]\n280 static svn_error_t *readbuf_getchar(svn_ra_svn_conn_t *conn,\napr_pool_t *pool,\n281                                     char *result)\n282 {\n283   if (conn->read_ptr == conn->read_end)\n284     SVN_ERR(readbuf_fill(conn, pool));\n285   *result = *conn->read_ptr++;\t<-------- SEGFAULT happens here\n286   return SVN_NO_ERROR;\n287 }\n\n===========================================================================\n\ngdb backtrace:\n\nr54 = f80e8d0ad785cae5a4abfb1fdd04b31167553ab0 (trunk)\n        D       collector/src/testCollector.h\n        M       collector/src/rcvIpfix.h\n        M       collector/src/rcvMessage.c\n        M       collector/src/common.c\n        M       collector/src/rcvIpfix.c\n        M       collector/src/common.h\nr55 = 3fddc1de138e9457385ff43111bcaf6f82884525 (trunk)\n\nProgram received signal SIGSEGV, Segmentation fault.\n[Switching to Thread -1210452288 (LWP 17426)]\n0xb745f0a6 in readbuf_getchar (conn=0x877bf78, pool=0x88a6178, \n    result=0xbfea011f \"\\bL:F�L:F�X\\001�\\006F�x�w\\bxa\\212\\bD\\001�230��x�w\\b�\\212\\b�F�\\002\")\n    at /tmp/buildd/subversion-1.4.3dfsg1/subversion/libsvn_ra_svn/marshal.c:285\n285       *result = *conn->read_ptr++;\n(gdb) bt\n#0  0xb745f0a6 in readbuf_getchar (conn=0x877bf78, pool=0x88a6178, \n    result=0xbfea011f \"\\bL:F�L:F�X\\001�\\006F�x�w\\bxa\\212\\bD\\001�230��x�w\\b�\\212\\b�F�\\002\")\n    at /tmp/buildd/subversion-1.4.3dfsg1/subversion/libsvn_ra_svn/marshal.c:285\n#1  0xb745f0e7 in readbuf_getchar_skip_whitespace (conn=0x877bf78, pool=0x88a6178, \n    result=0xbfea011f \"\\bL:F�L:F�X\\001�\\006F�x�w\\bxa\\212\\bD\\001�230��x�w\\b�\\212\\b�F�\\002\")\n    at /tmp/buildd/subversion-1.4.3dfsg1/subversion/libsvn_ra_svn/marshal.c:294\n#2  0xb74600f4 in svn_ra_svn_read_item (conn=0x877bf78, pool=0x88a6178, item=0xbfea0144)\n    at /tmp/buildd/subversion-1.4.3dfsg1/subversion/libsvn_ra_svn/marshal.c:621\n#3  0xb7460629 in svn_ra_svn_read_tuple (conn=0x877bf78, pool=0x88a6178, fmt=0xb7462607 \"wl\")\n    at /tmp/buildd/subversion-1.4.3dfsg1/subversion/libsvn_ra_svn/marshal.c:741\n#4  0xb7460907 in svn_ra_svn_read_cmd_response (conn=0x877bf78, pool=0x88a6178, fmt=0xb7461372 \"lc\")\n    at /tmp/buildd/subversion-1.4.3dfsg1/subversion/libsvn_ra_svn/marshal.c:799\n#5  0xb745381e in handle_auth_request (sess=0x877e1e8, pool=0x88a6178)\n    at /tmp/buildd/subversion-1.4.3dfsg1/subversion/libsvn_ra_svn/client.c:346\n#6  0xb74562b2 in ra_svn_check_path (session=0x8778090, path=0x8899d48 \"tags/collector-orig\", rev=56, kind=0xbfea02c8, pool=0x88a6178)\n    at /tmp/buildd/subversion-1.4.3dfsg1/subversion/libsvn_ra_svn/client.c:1284\n#7  0xb7495fd8 in svn_ra_check_path (session=0x8778090, path=0x8899d48 \"tags/collector-orig\", revision=56, kind=0xbfea02c8, \n    pool=0x88a6178) at /tmp/buildd/subversion-1.4.3dfsg1/subversion/libsvn_ra/ra_loader.c:564\n#8  0xb74c2c94 in _wrap_svn_ra_check_path (my_perl=0x814e008, cv=0x85e1a94) at svn_ra.c:6019\n#9  0x080bdad1 in Perl_pp_entersub ()\n#10 0x080bc3a9 in Perl_runops_standard ()\n#11 0x08063a1b in perl_run ()\n#12 0x0805ffd1 in main ()\n(gdb)\n\nI'm a little lost in debuging this any further. So if anyone could give\nme some advice ... feel free to contact me by mail or in #git\n(nickname siprbaum)\n\n-Peter\n\nMy system is debian etch with backported subversion + patch in [2] and git from\ndebian unstable/experimental\nii  git-core                        1.5.1.3-1\nii  git-svn                         1.5.1.3-1\nii  libsvn-perl                     1.4.3dfsg1-1\nii  libsvn1                         1.4.3dfsg1-1\nii  subversion                      1.4.3dfsg1-1\n\n[1]: http://wwwcip.informatik.uni-erlangen.de/~siprbaum/git-svn-segfault.txt\n[2]: http://svn.haxx.se/dev/archive-2007-01/0936.shtml\n"},{"id":"42004","messageId":"20070513082118.GC1168@muzzle","threadId":"7700","inReplyTo":"20070503123512.GA6500@xp.machine.xx","subject":"Re: Segmentation fault in git-svn","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-05-13T08:21:19Z","receivedAt":"2007-05-13T08:21:19Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Peter Baumann <waste.manager@gmx.de> wrote:\n> On Mon, Apr 16, 2007 at 03:17:55PM -0700, Steven Grimm wrote:\n> >  I expect this is really a libsvn bug, but git-svn triggers it, so I'm hoping \n> >  someone else has run into and solved it, or at least that someone can \n> >  reproduce it.\n> > \n> >  If I try to clone the \"memcached\" public repository with the command line\n> > \n> >   git-svn clone --branches=branches --trunk=trunk \n> >  http://code.sixapart.com/svn/memcached\n> \n> I'm getting segfaults in git-svn, too.\n> \n> This command segfaults reproducably in r55 while running\n> \n> \tgit svn clone svn://svn.berlios.de/vermont vermont \\\n> \t\t-T trunk -b branches -t tags\n> \n\nBoth repositories seem to be cloning fine after the\npatch here:\n\nhttp://permalink.gmane.org/gmane.comp.version-control.git/47128\n\nI really don't know what's going on with libsvn, either :(\n\n-- \nEric Wong\n"},{"id":"42059","messageId":"46478B74.8010005@midwinter.com","threadId":"7700","inReplyTo":"20070513082118.GC1168@muzzle","subject":"Re: Segmentation fault in git-svn","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-05-13T22:04:36Z","receivedAt":"2007-05-13T22:04:36Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"I can confirm that the patch fixes the segfault for me too. Thanks!\n\n-Steve\n"},{"id":"42104","messageId":"20070514090241.GA5493@xp.machine.xx","threadId":"7700","inReplyTo":"46478B74.8010005@midwinter.com","subject":"Re: Segmentation fault in git-svn","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-05-14T09:02:41Z","receivedAt":"2007-05-14T09:02:41Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Sun, May 13, 2007 at 03:04:36PM -0700, Steven Grimm wrote:\n>  I can confirm that the patch fixes the segfault for me too. Thanks!\n> \n>  -Steve\n> \n\nI can (hopefully) confirm this, too.\n\n-Peter\n\n\nSide Note:\n\nI tried it yesterday and got a message which\nlooks something alike \"connection closed ...\" and after continuing the\nimport I got an segfault. But as I couldn't reproduce this today, it\nseems that it was just a flacky connection and after the closed\nconnection the repo was just in an inconsistent state.\n\nI'll propably try to import this repo a few more times, just to check\nif it is really fixed.\n"}]}