1.3.2 git-clone segfaults

Dear Git maintainers:

I have twice downloaded git-1.3.2, most recently the git-1.3.2.tar.gz source package from http://www.t2-project.org/packages/git.html. Both the prebuilt version and the source version, built with gcc 3.2.3 on x86/Linux, run into trouble when executing this command:

% git --exec-path=/usr/local/downloads/git-1.3.2 clone http:// www.denx.de/git/linux-2.6-denx.git linux-2.6-denx

Both git operations proceed with some 18,000+ lines of output, culminating in this message:

got 243a15f54002445f5b8b4938981ec90430b73ec6 got 03914b7e41b17871aea961f6522ec4ce26a4f8ed got a305ae2e44b6dde305d3afe241768e32c47d8907 got 33a653913d942fa35c263edf1d019f36f4e0f5b1 got f13f49afe198cc0d59e998fe3a6e721d70fca6b4 error: The requested URL returned error: 405 (curl_result = 22, http_code = 405, sha1 = b323ff5779672c77b6adfba1c1bdc87f4981f85c) error: Unable to find b323ff5779672c77b6adfba1c1bdc87f4981f85c under http://www.denx.de/git/linux-2.6-denx.git/ Cannot obtain needed blob b323ff5779672c77b6adfba1c1bdc87f4981f85c while processing commit ea989b3245993f95e58e6c0320bf6165a949b072. Waiting for http://www.denx.de/git/linux-2.6-denx.git/objects/ 31/548303ee3767095f86efb47696ce433662450e /usr/local/downloads/git-1.3.2/git-clone: line 323: 25972 Segmentation fault git-http-fetch -v -a -w "$tname" "$name" "$1/"

I have also tested git-1.2.3 built from source, and it works dandily.

Please let me know if I can supply more information or if I'm misusing the command.

Thanks,

Bill Yoder Git Newbie

On Wed, May 17, 2006 at 01:32:39PM -0500, Bill Yoder wrote:

I reported this same issue to Nick Hengeveld and he said he'll take a look at it. this is also Gentoo Bug #133412 [1].

- ferdy

[1] https://bugs.gentoo.org/show_bug.cgi?id=133412

Bill Yoder <byoder@cs.utexas.edu> writes:

Could you try 1.3.3?

Dear Junio (and Fernando):

Here are the last few lines of output from 1.3.3, cooked with gcc 3.2.3:

Getting alternates list for http://www.denx.de/git/linux-2.6-denx.git/ got b603ba9e9b5482d3e80fc8e0fa96bb9a943502ff got 1635ee25918fc19ea613d1e8dbcb672075220efb got dd7d627bf66f306b4ee9401f06ed4fb574896a85 got c771a7db9871bfa3f3c76b78c1369111c4be767b got 374e20ad8b0d02f15fbcaa5315e272eabd6c4f76 got a8bef1d1371cc999ce6882d355c7554ca7738173 got ab08f35cbc355f4b2058d88ff289552f202ea5b4 Getting pack list for http://www.denx.de/git/linux-2.6-denx.git/ got 92297ff24e8525de2617dff728b3420a4649f66a got 93dcbe1abb4c83b65cc6af59fb84c3c5e16effbb got 41ecbb847f32f301a7ecd30b6438fea702886a33 got 94f557fa46369ec94ec718d25616ceb0b73fd2d2 got 09e00433c78e267b37b3f485c0d877de780a0674 got da7c09e4ede6e83198bf1ab5f16c571b0cc214ee got 85533ec5aaa17f4146452a16ef61ca40fc601c80 got 50e338d2ffda9cb5a835d67849e38ae0ceba1647 /usr/local/downloads/git-1.3.3/git-clone: line 323: 1124 Segmentation fault git-http-fetch -v -a -w "$tname" "$name" "$1/"

Regards, Bill

On Wed, 2006-05-17 at 13:32 -0500, Bill Yoder wrote:

I've seen git-http-fetch segfaults many times when cloning qgit, but it's hard to reproduce on demand.

I think you should compile git without optimizations and allow coredumps (ulimit -c unlimited), then load git-http-fetch in gdb with the core (gdb --core=core git-http-fetch) and run bt to see the backtrace.

On Wed, 2006-05-17 at 15:29 -0400, Pavel Roskin wrote:

Also comment out both "trap" invocations in git-clone, or the coredump will be deleted.

That's what I've got on Fedora Core 5 x86_64 with glibc and curl debug info installed:

#0  __strncasecmp (s1=Variable "s1" is not available.
) at strncase.c:68
68        while ((result = TOLOWER (*p1) - TOLOWER (*p2++)) == 0)
(gdb) where
#0  __strncasecmp (s1=Variable "s1" is not available.
) at strncase.c:68
#1  0x00000031f3e26c09 in curl_strnequal (first=Variable "first" is not available.
) at strequal.c:60
#2  0x00000031f3e0f43a in checkheaders (data=Variable "data" is not available.
) at http.c:119
#3  0x00000031f3e10cf9 in Curl_http (conn=0x1c421c0, done=Variable "done" is not available.
) at http.c:1580
#4  0x00000031f3e1a858 in Curl_do (connp=0x83af88, done=0x7fff29c97ebb "\001\001")
    at url.c:3841
#5  0x00000031f3e28f22 in curl_multi_perform (multi_handle=0x53b590, 
    running_handles=0x7fff29c97ef8) at multi.c:526
#6  0x00000000004040c0 in step_active_slots () at http.c:376
#7  0x000000000040412c in run_active_slot (slot=0x546690) at http.c:400
#8  0x0000000000403e44 in http_cleanup () at http.c:275
#9  0x00000000004077d7 in main (argc=7, argv=0x7fff29c98258) at http-fetch.c:1274
(gdb) p p1
$1 = (const unsigned char *) 0x0
(gdb) p p2
$2 = (const unsigned char *) 0x31f3e2e817 "User-Agent:"
(gdb)

Looks like a curl bug to me.  curl 7.15.1, glibc 2.4, git master branch.

On Wed, 17 May 2006, Pavel Roskin wrote:

If the thing is fixed by turning off DAV support (and I thought somebody reported it was), maybe we should turn that off by default? Ie, make NO_EXPAT be the default, and you have to explicitly turn it off.

		Linus