{"thread":{"id":"4376","subject":"git-http-fetch segfault backtrace","startedAt":"2006-06-02T15:47:48Z","lastAt":"2006-06-02T15:47:48Z","messageCount":1,"participants":["Becky Bruce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"21104","messageId":"43D574AA-92CF-42E6-BB89-9F57533D1E91@freescale.com","threadId":"4376","inReplyTo":null,"subject":"git-http-fetch segfault backtrace","fromName":"Becky Bruce","fromEmail":"becky.bruce@freescale.com","sentAt":"2006-06-02T15:47:48Z","receivedAt":"2006-06-02T15:47:48Z","isPatch":false,"sender":{"key":"becky.bruce@freescale.com","avatar":null},"body":"\nI've been having problems with git-http-fetch segfaulting for several  \ngit versions now.  I've been watching the list and have seen other  \ncomplaints about similar problems, but the issue I'm hitting seems to  \nbe slightly different.  Any insight anyone has here is greatly  \nappreciated.  I've included what information I have, and if there's  \nany other information or experiments anyone would like me to try,  \nI'll be happy to give it a go.\n\nSome information:\n- the git version is top of tree as of 1pm 6/1.  I pulled it from  \nhttp://www.kernel.org/pub/scm/git/git.git\n- I am running on an i686 Linux machine: uname -a returns\nLinux machinename 2.4.21-32.EL #1 Fri Apr 15 21:29:19 EDT 2005 i686  \ni686 i386 GNU/Linux\n- my curl version is\ncurl 7.10.6 (i386-redhat-linux-gnu) libcurl/7.10.6 OpenSSL/0.9.7a  \nipv6 zlib/1.1.4.  git with the same curl version appears to work fine  \non x86_64 systems here.\n- As far as I can tell, this problem seems to have appeared sometime  \nafter git 1.2.4\n\n\nI compiled git without optimizations and ran git-http-fetch via gdb  \nto see what's going on.  Here's the backtrace:\n\n(gdb) run -v -a -w heads/html heads/html http://www.kernel.org/pub/ \nscm/git/git.git/\nStarting program: /tmp/install/bin/git-http-fetch -v -a -w heads/html  \nheads/html http://www.kernel.org/pub/scm/git/git.git/\nwalk bb8fb05ed082c81af81f9eecf356f993e2ef83b7\nwalk f31d9f5bcd0a1c236d8277df39c74927917ffb8f\nGetting alternates list for http://www.kernel.org/pub/scm/git/git.git/\nGetting pack list for http://www.kernel.org/pub/scm/git/git.git/\n\nProgram received signal SIGSEGV, Segmentation fault.\n0x00eed07c in memcpy () from /lib/tls/libc.so.6\n(gdb) bt\n#0  0x00eed07c in memcpy () from /lib/tls/libc.so.6\n#1  0x0804a6db in fread_buffer (ptr=0x9323a01, eltsize=1,  \nnmemb=16384, buffer=0xbfffb830)\n     at http.c:38\n#2  0x0012c438 in Curl_getinfo () from /usr/lib/libcurl.so.2\n#3  0x0012ce49 in Curl_readwrite () from /usr/lib/libcurl.so.2\n#4  0x001314f2 in curl_multi_perform () from /usr/lib/libcurl.so.2\n#5  0x0804afb9 in get_active_slot () at http.c:304\n#6  0x0804d41d in fetch_indices (repo=0x9309498) at http-fetch.c:910\n#7  0x0804d666 in fetch_pack (repo=0x9309498, sha1=0x9312390 \"Ѥ???r# \n\\032??&?\\aC??:?+'[?\\005\\b\")\n     at http-fetch.c:977\n#8  0x0804dd41 in fetch (sha1=0x9312390 \"Ѥ???r#\\032??&?\\aC??:?+'[?\\005 \n\\b\") at http-fetch.c:1129\n#9  0x0804a4a9 in loop () at fetch.c:166\n#10 0x0804a64f in pull (target=0xbfffefe1 \"heads/html\") at fetch.c:218\n#11 0x0804e2c9 in main (argc=7, argv=0xbfffcae4) at http-fetch.c:1269\n\nI also did some poking around, and it looks like the call to  \nfread_buffer that causes the problem (it's the 3rd call, in this  \ncase) has a potentially bogus buffer->posn (at least, it seems a  \nlittle ridiculous to me).... Note that the previous call to fread  \nresulted in a 0 size.\n\nStarting program: /tmp/install/bin/git-http-fetch -v -a -w heads/html  \nheads/html http://www.kernel.org/pub/scm/git/git.git/\n[/_TOOLS_/plat/local-/ppc-/login]\nInstalling oss-/1.0.0\nwalk bb8fb05ed082c81af81f9eecf356f993e2ef83b7\nwalk f31d9f5bcd0a1c236d8277df39c74927917ffb8f\nGetting alternates list for http://www.kernel.org/pub/scm/git/git.git/\nGetting pack list for http://www.kernel.org/pub/scm/git/git.git/\n\nBreakpoint 1, fread_buffer (ptr=0x914fa01, eltsize=1, nmemb=16384,  \nbuffer=0xbfffb9a0)\n     at http.c:35\n35              size_t size = eltsize * nmemb;\n(gdb) step\n36              if (size > buffer->size - buffer->posn)\n(gdb) step\n37                      size = buffer->size - buffer->posn;\n(gdb) p/x size\n$1 = 0x4000\n(gdb) p/x buffer->size\n$2 = 0x5e\n(gdb) p/x buffer->posn\n$3 = 0x0\n(gdb) c\nContinuing.\n\nBreakpoint 1, fread_buffer (ptr=0x914fa01, eltsize=1, nmemb=16384,  \nbuffer=0xbfffb9a0)\n     at http.c:35\n35              size_t size = eltsize * nmemb;\n(gdb) step\n36              if (size > buffer->size - buffer->posn)\n(gdb) p/x size\n$4 = 0x4000\n(gdb) p/x buffer->size\n$5 = 0x5e\n(gdb) p/x buffer->posn\n$6 = 0x5e\n(gdb) c\nContinuing.\n\nBreakpoint 1, fread_buffer (ptr=0x914fa01, eltsize=1, nmemb=16384,  \nbuffer=0xbfffb9a0)\n     at http.c:35\n35              size_t size = eltsize * nmemb;\n(gdb) step\n36              if (size > buffer->size - buffer->posn)\n(gdb) p/x size\n$7 = 0x4000\n(gdb) p/x buffer->size\n$8 = 0x7\n(gdb) p/x buffer->posn\n$9 = 0xbfffcc54\n(gdb)\n\nWe thought perhaps the problem was related to CURL MULTI, but we set  \nhttp.maxrequests to 1, we get the same behavior.  FYI - if you turn  \noff USE_CURL_MULTI, git no longer builds.  There is stuff that uses  \nthe curlm variable that is not inside the ifdefs.\n\nThanks,\nB\n"}]}