{"thread":{"id":"6127","subject":"Re: http git and curl 7.16.0","startedAt":"2006-12-27T14:57:46Z","lastAt":"2007-01-01T08:08:02Z","messageCount":5,"participants":["Horst H. von Brand","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"30355","messageId":"200612271457.kBREvkj2011916@laptop13.inf.utfsm.cl","threadId":"6127","inReplyTo":"skimo@kotnet.org","subject":"Re: http git and curl 7.16.0","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-12-27T14:57:46Z","receivedAt":"2006-12-27T14:57:46Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Sven Verdoolaege wrote:\n> On Sat, Nov 18, 2006 at 08:07:08AM +0400, George Sherwood wrote:\n> > I seem to be having a problem doing an http checkout with git built\n> > with curl 7.16.0 enabled. If I build against curl 7.16.0 and try a\n> > clone, I get:\n\n> > git clone http://dmlb2000.homelinux.org/~dmlb2000/git-repos/local/castfs.git\n> > error: Unable to start request error: Could not interpret heads/master\n> > as something to pull\n> > \n> > If I rebuild git against curl 7.15.5 then I get:\n> [..]\n> > and the checkout finishes.\n> > \n> > Has any one else seen this?\n\n> FWIW, I've seen the same with curl 7.16.0 on a Solaris 9 machine.\n> It worked fine with curl 7.15.0.\n\nIt works fine for me on Aurora Corona (sparc) with curl-7.15.5-1.al3, while\nit fails as above on Fedora rawhide (i386) with curl-7.16.0-4.fc7.\n\nFurthermore, with new curl pulling from HTTP repos when there are updates\ngives double free errors and a crash.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"},{"id":"30359","messageId":"7vlkkt5d49.fsf@assigned-by-dhcp.cox.net","threadId":"6127","inReplyTo":"200612271457.kBREvkj2011916@laptop13.inf.utfsm.cl","subject":"Re: http git and curl 7.16.0","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-27T19:53:58Z","receivedAt":"2006-12-27T19:53:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Horst H. von Brand\" writes:\n\n> Sven Verdoolaege wrote:\n>> On Sat, Nov 18, 2006 at 08:07:08AM +0400, George Sherwood wrote:\n>> > I seem to be having a problem doing an http checkout with git built\n>> > with curl 7.16.0 enabled. If I build against curl 7.16.0 and try a\n>> > clone, I get:\n> ...\n>> > git clone http://dmlb2000.homelinux.org/~dmlb2000/git-repos/local/castfs.git\n>> > error: Unable to start request error: Could not interpret heads/master\n>> > as something to pull\n>> > \n>> > If I rebuild git against curl 7.15.5 then I get:\n>> [..]\n>> > and the checkout finishes.\n>> > \n>> > Has any one else seen this?\n>\n>> FWIW, I've seen the same with curl 7.16.0 on a Solaris 9 machine.\n>> It worked fine with curl 7.15.0.\n>\n> It works fine for me on Aurora Corona (sparc) with curl-7.15.5-1.al3, while\n> it fails as above on Fedora rawhide (i386) with curl-7.16.0-4.fc7.\n>\n> Furthermore, with new curl pulling from HTTP repos when there are updates\n> gives double free errors and a crash.\n\nHmmm. Could somebody please run http-fetch under gdb and see\nwhere it breaks? The exact command line you need to use would\nbe obtainable by running \"sh -x git-clone\" once.\n\n[jc: Nick CC'ed, although I haven't seen him on the list for\nsome time...]\n"},{"id":"30365","messageId":"7v8xgt57wu.fsf@assigned-by-dhcp.cox.net","threadId":"6127","inReplyTo":"7vlkkt5d49.fsf@assigned-by-dhcp.cox.net","subject":"Re: http git and curl 7.16.0","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-27T21:46:25Z","receivedAt":"2006-12-27T21:46:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n>>> FWIW, I've seen the same with curl 7.16.0 on a Solaris 9 machine.\n>>> It worked fine with curl 7.15.0.\n>>\n>> It works fine for me on Aurora Corona (sparc) with curl-7.15.5-1.al3, while\n>> it fails as above on Fedora rawhide (i386) with curl-7.16.0-4.fc7.\n>>\n>> Furthermore, with new curl pulling from HTTP repos when there are updates\n>> gives double free errors and a crash.\n>\n> Hmmm. Could somebody please run http-fetch under gdb and see\n> where it breaks? The exact command line you need to use would\n> be obtainable by running \"sh -x git-clone\" once.\n>\n> [jc: Nick CC'ed, although I haven't seen him on the list for\n> some time...]\n\nWhen we do not have NO_CURL_EASY_DUPHANDLE defined, http.c\nprepares a single \"CURL *curl_default\" with get_curl_handle(),\nand new request slots clone it using curl_easy_duphandle().\nHowever, the returned \"clone\" somehow forgets to set the \"magic\"\nnumber that says it is a GOOD_EASY_HANDLE(). This missing magic\nnumber is checked by cURL library in curl_multi_add_handle(),\nwhich we call from start_active_slot(). Hence the request\nfails.\n\nNow, I do not know cURL, and cannot tell if it is just a bug in\neasy-duphandle of curl 7.16.0, or if we are not supposed to be\nusing the \"easy\" interface when dealing with multi fetch. In\neither case, the attached patch seems to fix it for me.\n\nI am NOT CC'ing curl-library@cool.haxx.se mailing list since I\ndo not want to subscribe only to be able to post, but some kind\nsouls who are subscribers could forward the issue to them to\ndetermine if we need to fix our code (and if so how), or if we\nneed to wait for them to fix curl_easy_duphandle().\n\n-- >8 --\n\ndiff --git a/http.h b/http.h\nindex 6e12e41..70b18dd 100644\n--- a/http.h\n+++ b/http.h\n@@ -18,7 +18,7 @@\n #define curl_global_init(a) do { /* nothing */ } while(0)\n #endif\n \n-#if LIBCURL_VERSION_NUM < 0x070c04\n+#if 1 || (LIBCURL_VERSION_NUM < 0x070c04)\n #define NO_CURL_EASY_DUPHANDLE\n #endif\n \n"},{"id":"30452","messageId":"7vfyazttzm.fsf_-_@assigned-by-dhcp.cox.net","threadId":"6127","inReplyTo":"7v8xgt57wu.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH/RFT] Work around http-fetch built with cURL 7.16.0","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-29T00:40:13Z","receivedAt":"2006-12-29T00:40:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"It appears that curl_easy_duphandle() from libcurl 7.16.0\nreturns a curl session handle which fails GOOD_MULTI_HANDLE()\ncheck in curl_multi_add_handle(). This causes fetch_ref() to\nfail because start_active_slot() cannot start the request.\n\nFor now, check for 7.16.0 to work this issue around.\n\nSigned-off-by: Junio C Hamano \n---\n\n * I think people who were having trouble with cURL 7.16.0 want\n to have the issue resolved before v1.5.0-rc1. Please test\n and report, or else ;-).\n\n http.h | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/http.h b/http.h\nindex 6e12e41..324fcf4 100644\n--- a/http.h\n+++ b/http.h\n@@ -18,7 +18,7 @@\n #define curl_global_init(a) do { /* nothing */ } while(0)\n #endif\n \n-#if LIBCURL_VERSION_NUM < 0x070c04\n+#if (LIBCURL_VERSION_NUM < 0x070c04) || (LIBCURL_VERSION_NUM == 0x071000)\n #define NO_CURL_EASY_DUPHANDLE\n #endif\n \n-- \n1.5.0.rc0.gf5c587\n"},{"id":"30614","messageId":"7vbqlj890d.fsf@assigned-by-dhcp.cox.net","threadId":"6127","inReplyTo":"20070101114252.6a76269e@athlon","subject":"Re: http git and curl 7.16.0","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-01T08:08:02Z","receivedAt":"2007-01-01T08:08:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"George Sherwood writes:\n\n> I CC'ed the mailing curl mailing list and according to the response\n> this problem is fixed in the latest cvs version of curl with this\n> commit:\n>\n> curl_easy_duphandle() sets the magic number in the new handle\n>\n> I have confirmed this works now git 1.4.4.3\n\nThanks, so it was a breakage on the .0 release on their side.\n\nI'll leave this in place for now:\n\n #if (LIBCURL_VERSION_NUM < 0x070c04) || (LIBCURL_VERSION_NUM == 0x071000)\n #define NO_CURL_EASY_DUPHANDLE\n #endif\n\nwhich specifically marks 7.16.0 as dud.\n"}]}