http git and curl 7.16.0
Quoted 9 lines · Sven Verdoolaege
Quoted 8 lines · George Sherwood
I seem to be having a problem doing an http checkout with git built with curl 7.16.0 enabled. If I build against curl 7.16.0 and try a clone, I get:
git clone http://dmlb2000.homelinux.org/~dmlb2000/git-repos/local/castfs.git
error: Unable to start request error: Could not interpret heads/master as something to pull
Quoted 8 lines
Quoted 1 line
If I rebuild git against curl 7.15.5 then I get:
[..]
Quoted 3 lines
and the checkout finishes.
Has any one else seen this?
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.
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
Quoted 16 lines · Horst H. von Brand
Quoted 4 lines · Sven Verdoolaege
Quoted 3 lines · George Sherwood
I seem to be having a problem doing an http checkout with git built with curl 7.16.0 enabled. If I build against curl 7.16.0 and try a clone, I get:
...
Quoted 9 lines
Quoted 5 lines
git clone http://dmlb2000.homelinux.org/~dmlb2000/git-repos/local/castfs.git
error: Unable to start request error: Could not interpret heads/master as something to pullIf I rebuild git against curl 7.15.5 then I get:
[..]
Quoted 3 lines
and the checkout finishes.
Has any one else seen this?
Quoted 8 lines
Quoted 2 lines
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...]
Quoted 23 lines · Junio C Hamano
Quoted 22 lines · Horst H. von Brand
Quoted 4 lines · Sven Verdoolaege
Quoted 3 lines · George Sherwood
I seem to be having a problem doing an http checkout with git built with curl 7.16.0 enabled. If I build against curl 7.16.0 and try a clone, I get:
...
Quoted 4 lines
Quoted 4 lines
git clone http://dmlb2000.homelinux.org/~dmlb2000/git-repos/local/castfs.git
error: Unable to start request error: Could not interpret heads/master as something to pullQuoted 8 lines
Quoted 1 line
If I rebuild git against curl 7.15.5 then I get:
[..]
Quoted 3 lines
and the checkout finishes.
Has any one else seen this?
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.
Quoted 6 lines
Quoted 2 lines
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.
It crashes the kernel for me here :-(
I tried to chop down a tig repo a few commits from the top for checking out the crash I'm seeing (only when pulling from a remote repo by HTTP, and it is not up to date here) by doing:
cp -r tig tig.tst cd tig.tst git reset --hard HEAD~3 git prune
But now git-pull /doesn't/ fetch anything, so I see no crash. What am I doing wrong here?
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
Quoted 11 lines · Horst H. von Brand
I tried to chop down a tig repo a few commits from the top for checking out the crash I'm seeing (only when pulling from a remote repo by HTTP, and it is not up to date here) by doing:
cp -r tig tig.tst cd tig.tst git reset --hard HEAD~3 git pruneBut now git-pull /doesn't/ fetch anything, so I see no crash. What am I doing wrong here?
Another ref points at the same commit as what ORIG_HEAD points at, so there wasn't anything to fetch as you already had that commit.
Its probably a tag, a ref under refs/remotes, or another branch...
Signature · 1 line
Shawn.
Quoted 9 lines · Junio C Hamano
Quoted 8 lines
Quoted 2 lines
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.
Quoted 6 lines
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 [email protected] 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 --
http.h +1 -1
@@ -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
Quoted 7 lines · George Sherwood
I CC'ed the mailing curl mailing list and according to the response this problem is fixed in the latest cvs version of curl with this commit:
curl_easy_duphandle()sets the magic number in the new handleI have confirmed this works now git 1.4.4.3
Thanks, so it was a breakage on the .0 release on their side.
I'll leave this in place for now:
#if (LIBCURL_VERSION_NUM < 0x070c04) || (LIBCURL_VERSION_NUM == 0x071000)
#define NO_CURL_EASY_DUPHANDLE
#endifwhich specifically marks 7.16.0 as dud.
[PATCH/RFT] Work around http-fetch built with cURL 7.16.0
In reply to Junio C HamanoIt appears that curl_easy_duphandle() from libcurl 7.16.0 returns a curl session handle which fails GOOD_MULTI_HANDLE() check in curl_multi_add_handle(). This causes fetch_ref() to fail because start_active_slot() cannot start the request.
For now, check for 7.16.0 to work this issue around.
---
* I think people who were having trouble with cURL 7.16.0 want to have the issue resolved before v1.5.0-rc1. Please test and report, or else ;-).
http.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
http.h +1 -1
@@ -18,7 +18,7 @@ #define curl_global_init(a) do { /* nothing */ } while(0)#endif -#if LIBCURL_VERSION_NUM <0x070c04 +#if (LIBCURL_VERSION_NUM <0x070c04 ) || (LIBCURL_VERSION_NUM ==0x071000 )#define NO_CURL_EASY_DUPHANDLE #endif
Signature · 1 line
1.5.0.rc0.gf5c587
Re: [PATCH/RFT] Work around http-fetch built with cURL 7.16.0
Quoted 5 lines · Junio C Hamano
It appears that
curl_easy_duphandle()from libcurl 7.16.0 returns a curl session handle which failsGOOD_MULTI_HANDLE()check incurl_multi_add_handle(). This causesfetch_ref()to fail becausestart_active_slot()cannot start the request.
Quoted 8 lines
For now, check for 7.16.0 to work this issue around.
Signed-off-by Junio C Hamano <[email protected]>---
* I think people who were having trouble with cURL 7.16.0 want to have the issue resolved before v1.5.0-rc1. Please test and report, or else ;-).
Checked it out. Now clone and pull both work here.
Thanks!
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513