Junio C Hamano <junkio@xxxxxxx> writes:
>>> FWIW, I've seen the same with curl 7.16.0 on a Solaris 9 machine.
>>> It worked fine with curl 7.15.0.
>>
>> It works fine for me on Aurora Corona (sparc) with curl-7.15.5-1.al3, while
>> it fails as above on Fedora rawhide (i386) with curl-7.16.0-4.fc7.
>>
>> Furthermore, with new curl pulling from HTTP repos when there are updates
>> gives double free errors and a crash.
>
> Hmmm. Could somebody please run http-fetch under gdb and see
> where it breaks? The exact command line you need to use would
> be obtainable by running "sh -x git-clone" once.
>
> [jc: Nick CC'ed, although I haven't seen him on the list for
> some time...]
When we do not have NO_CURL_EASY_DUPHANDLE defined, http.c
prepares a single "CURL *curl_default" with get_curl_handle(),
and new request slots clone it using curl_easy_duphandle().
However, the returned "clone" somehow forgets to set the "magic"
number that says it is a GOOD_EASY_HANDLE(). This missing magic
number is checked by cURL library in curl_multi_add_handle(),
which we call from start_active_slot(). Hence the request
fails.
Now, I do not know cURL, and cannot tell if it is just a bug in
easy-duphandle of curl 7.16.0, or if we are not supposed to be
using the "easy" interface when dealing with multi fetch. In
either case, the attached patch seems to fix it for me.
I am NOT CC'ing curl-library@xxxxxxxxxxxx mailing list since I
do not want to subscribe only to be able to post, but some kind
souls who are subscribers could forward the issue to them to
determine if we need to fix our code (and if so how), or if we
need to wait for them to fix curl_easy_duphandle().
-- >8 --
diff --git a/http.h b/http.h
index 6e12e41..70b18dd 100644
--- a/http.h
+++ b/http.h
@@ -18,7 +18,7 @@
#define curl_global_init(a) do { /* nothing */ } while(0)
#endif
-#if LIBCURL_VERSION_NUM < 0x070c04
+#if 1 || (LIBCURL_VERSION_NUM < 0x070c04)
#define NO_CURL_EASY_DUPHANDLE
#endif
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html