> Okay, first to clarify: since it isn't doing pipelning, only one easy handle
> should use one connectdata struct.

From reading lib/url.c I am under impression that the 'reuse =
ConnectionExists' stanza in url.c:3698 can select already used
connection to be used again. Seems like it is done without checking
if the pipelining is enabled. Though, I can be wrong.

> >Got the today's snapshot. SEGV again, but in another place. Both git-http-push
> >and git-http-fetch are dumping the core in the same place: lib/multi.c:1927
> >trying to dereference multi->connc->connects[i]->data. It is the right place
> >that is dereferencing the bad pointer, because ElectricFence is here and seems
> >to do its job ;))
>
> Ouch. That seems to imply that the multi->connc->connects[] array has been
> freed? That is done by lib/url.c:Curl_rm_connc() and should only by done on
> curl_multi_cleanup() when the multi interface is used...

No, that implies that the particular member of that array (in my case
it is multi->connc->connects[2]) was already freed or initialised with
the bad memory location.

I will try to stuff the multi.c with the debug statements around all
free() calls.

>
> >Need the clear testcase, will try to write one.
>
>It would be really great! If you fail to repeat it like that an alternative but
>harder (for us) approach would be if you could tell us an exact git version and
>recipe on how to use it against a puplic repo to repeat the problem.
>
> Oh, and do try to build libcurl with "configure --enable-debug" and make sure
> that git calls curl_memdebug("dump") before starting to use libcurl. It could
> possibly provide some clues.

Will try, thank you for the pointers!

-- 
Eygene