I've been having problems with git-http-fetch segfaulting for several
git versions now. I've been watching the list and have seen other
complaints about similar problems, but the issue I'm hitting seems to
be slightly different. Any insight anyone has here is greatly
appreciated. I've included what information I have, and if there's
any other information or experiments anyone would like me to try,
I'll be happy to give it a go.
Some information:
- the git version is top of tree as of 1pm 6/1. I pulled it from
http://www.kernel.org/pub/scm/git/git.git
- I am running on an i686 Linux machine: uname -a returns
Linux machinename 2.4.21-32.EL #1 Fri Apr 15 21:29:19 EDT 2005 i686
i686 i386 GNU/Linux
- my curl version is
curl 7.10.6 (i386-redhat-linux-gnu) libcurl/7.10.6 OpenSSL/0.9.7a
ipv6 zlib/1.1.4. git with the same curl version appears to work fine
on x86_64 systems here.
- As far as I can tell, this problem seems to have appeared sometime
after git 1.2.4
I compiled git without optimizations and ran git-http-fetch via gdb
to see what's going on. Here's the backtrace:
(gdb) run -v -a -w heads/html heads/html http://www.kernel.org/pub/
scm/git/git.git/
Starting program: /tmp/install/bin/git-http-fetch -v -a -w heads/html
heads/html http://www.kernel.org/pub/scm/git/git.git/
walk bb8fb05ed082c81af81f9eecf356f993e2ef83b7
walk f31d9f5bcd0a1c236d8277df39c74927917ffb8f
Getting alternates list for http://www.kernel.org/pub/scm/git/git.git/
Getting pack list for http://www.kernel.org/pub/scm/git/git.git/
Program received signal SIGSEGV, Segmentation fault.
0x00eed07c in memcpy () from /lib/tls/libc.so.6
(gdb) bt
#0 0x00eed07c in memcpy () from /lib/tls/libc.so.6
#1 0x0804a6db in fread_buffer (ptr=0x9323a01, eltsize=1,
nmemb=16384, buffer=0xbfffb830)
at http.c:38
#2 0x0012c438 in Curl_getinfo () from /usr/lib/libcurl.so.2
#3 0x0012ce49 in Curl_readwrite () from /usr/lib/libcurl.so.2
#4 0x001314f2 in curl_multi_perform () from /usr/lib/libcurl.so.2
#5 0x0804afb9 in get_active_slot () at http.c:304
#6 0x0804d41d in fetch_indices (repo=0x9309498) at http-fetch.c:910
#7 0x0804d666 in fetch_pack (repo=0x9309498, sha1=0x9312390 "Ѥ???r#
\032??&?\aC??:?+'[?\005\b")
at http-fetch.c:977
#8 0x0804dd41 in fetch (sha1=0x9312390 "Ѥ???r#\032??&?\aC??:?+'[?\005
\b") at http-fetch.c:1129
#9 0x0804a4a9 in loop () at fetch.c:166
#10 0x0804a64f in pull (target=0xbfffefe1 "heads/html") at fetch.c:218
#11 0x0804e2c9 in main (argc=7, argv=0xbfffcae4) at http-fetch.c:1269
I also did some poking around, and it looks like the call to
fread_buffer that causes the problem (it's the 3rd call, in this
case) has a potentially bogus buffer->posn (at least, it seems a
little ridiculous to me).... Note that the previous call to fread
resulted in a 0 size.
Starting program: /tmp/install/bin/git-http-fetch -v -a -w heads/html
heads/html http://www.kernel.org/pub/scm/git/git.git/
[/_TOOLS_/plat/local-/ppc-/login]
Installing oss-/1.0.0
walk bb8fb05ed082c81af81f9eecf356f993e2ef83b7
walk f31d9f5bcd0a1c236d8277df39c74927917ffb8f
Getting alternates list for http://www.kernel.org/pub/scm/git/git.git/
Getting pack list for http://www.kernel.org/pub/scm/git/git.git/
Breakpoint 1, fread_buffer (ptr=0x914fa01, eltsize=1, nmemb=16384,
buffer=0xbfffb9a0)
at http.c:35
35 size_t size = eltsize * nmemb;
(gdb) step
36 if (size > buffer->size - buffer->posn)
(gdb) step
37 size = buffer->size - buffer->posn;
(gdb) p/x size
$1 = 0x4000
(gdb) p/x buffer->size
$2 = 0x5e
(gdb) p/x buffer->posn
$3 = 0x0
(gdb) c
Continuing.
Breakpoint 1, fread_buffer (ptr=0x914fa01, eltsize=1, nmemb=16384,
buffer=0xbfffb9a0)
at http.c:35
35 size_t size = eltsize * nmemb;
(gdb) step
36 if (size > buffer->size - buffer->posn)
(gdb) p/x size
$4 = 0x4000
(gdb) p/x buffer->size
$5 = 0x5e
(gdb) p/x buffer->posn
$6 = 0x5e
(gdb) c
Continuing.
Breakpoint 1, fread_buffer (ptr=0x914fa01, eltsize=1, nmemb=16384,
buffer=0xbfffb9a0)
at http.c:35
35 size_t size = eltsize * nmemb;
(gdb) step
36 if (size > buffer->size - buffer->posn)
(gdb) p/x size
$7 = 0x4000
(gdb) p/x buffer->size
$8 = 0x7
(gdb) p/x buffer->posn
$9 = 0xbfffcc54
(gdb)
We thought perhaps the problem was related to CURL MULTI, but we set
http.maxrequests to 1, we get the same behavior. FYI - if you turn
off USE_CURL_MULTI, git no longer builds. There is stuff that uses
the curlm variable that is not inside the ifdefs.
Thanks,
B
-
: 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