error: git-svn died of signal 13

> Hi,
> 
> Just wanted to pass on a few reports about git-svn dying with SIGPIPE
> when trying to fetch large repositories.  It seems to fetch a few
> revisions, then die; the repositories can eventually be fetched
> successfully by restarting 'git svn fetch' again and again.
> 
> Some bug reporters have been very patient, but I don’t really know
> where to look or ask in solving this.  Attempts at tracing so far have
> given either too little or too much information to make any sense.
> 
> The problem goes back at least to v1.5.6.5.

> At the end of the git-svn process’s life, the last few function calls
> are these:
> 
>  - SVN::Ra::Reporter::finish_report and related functions
>  - _p_apr_pool_t::DESTROY (libsvn-perl cleaning up, presumably)
>  - SVN::Ra::Callbacks::open_tmp_file, called from
>    SVN::_Ra::svn_ra_do_update, called from
>    Git::SVN::Ra::do_update, called from
>    Git::SVN::Ra::gs_do_update
>  - Git::SVN::_set_repos_root
>  - starting a 'git update-index -z --index-info' to feed commands to
> 
> Maybe /tmp is filling up?  It is hard to know, since the SIGPIPE stops
> everything and we do not get any nice, simple error message describing
> what read or write would have received EPIPE.
> 
> See <http://bugs.debian.org/526989>, <http://bugs.debian.org/540150>,
> <http://thread.gmane.org/gmane.comp.version-control.git/85868/>.
> 
> Any insights?

>> Just wanted to pass on a few reports about git-svn dying with SIGPIPE
>> when trying to fetch large repositories.  It seems to fetch a few
>> revisions, then die; the repositories can eventually be fetched
>> successfully by restarting 'git svn fetch' again and again.
>> 
>> Some bug reporters have been very patient, but I don’t really know
>> where to look or ask in solving this.  Attempts at tracing so far have
>> given either too little or too much information to make any sense.
>> 
>> The problem goes back at least to v1.5.6.5.
>
> Hi Jonathan,
>
> Thanks for taking the time to look into this.  This has been a
> problem for a long time and very difficult to track down.
>
> One factor is that git svn continues happily afterwards so it's hard to
> reproduce and there's less incentive to look for a fix.
>
>> At the end of the git-svn process’s life, the last few function calls
>> are these:
>> 
>>  - SVN::Ra::Reporter::finish_report and related functions
>>  - _p_apr_pool_t::DESTROY (libsvn-perl cleaning up, presumably)
>>  - SVN::Ra::Callbacks::open_tmp_file, called from
>>    SVN::_Ra::svn_ra_do_update, called from
>>    Git::SVN::Ra::do_update, called from
>>    Git::SVN::Ra::gs_do_update
>>  - Git::SVN::_set_repos_root
>>  - starting a 'git update-index -z --index-info' to feed commands to
>> 
>> Maybe /tmp is filling up?  It is hard to know, since the SIGPIPE stops
>> everything and we do not get any nice, simple error message describing
>> what read or write would have received EPIPE.
>> 
>> See <http://bugs.debian.org/526989>, <http://bugs.debian.org/540150>,
>> <http://thread.gmane.org/gmane.comp.version-control.git/85868/>.
>> 
>> Any insights?
>
> Can somebody get an strace or core dump for the "git update-index"
> call?  Or even an strace -f of the entire git svn invocation as well...

> 
> CCing those who reported the problem.  There is some debugging advice below,
> for anyone who wants to take a further stab at tracking this down.
> 
> Eric Wong wrote:
> > Can somebody get an strace or core dump for the "git update-index"
> > call?  Or even an strace -f of the entire git svn invocation as well...
>