On Tue, 2006-06-06 at 09:46 -0700, Nick Hengeveld wrote: > On Tue, Jun 06, 2006 at 12:19:19PM -0400, Pavel Roskin wrote: > > > On Mon, 2006-06-05 at 23:02 -0700, Junio C Hamano wrote: > > > - http-fetch fixes from Nick, which looked obviously correct. > > > I would appreciate test reports from people who saw breakages > > > on this one. > > > > I'm still getting a segfault with the current git from the "next" branch: > > > > $ git-clone http://www.denx.de/git/linux-2.6-denx.git > > ... > > got 4160b8334c53e0881cdc12c1f7d3d54fff883772 > > got 5f57f29efee48d84e235a8ff75a35e7e354227a7 > > got 681a9c73a2a321850404d4856f4738be47e17d15 > > got 29b0ddaa324e417abf153460d7d94fb67823a6ef > > got 23e7a5c7d2c13d98524b69f54378d887e1962fc8 > > /home/proski/bin/git-clone: line 29: 27271 Segmentation fault git-http-fetch -v -a -w "$tname" "$name" "$1/" It crashed again, in a different place: got d82e6dae84070951f625622229154cb32d3f2333 got c3e1d3e888d7b25c20d90ae4a7ecb8f5be420b98 got 2ed07112d683fa7cd1c72b0a31a7e95c6645543d got 2721e4c8184a9a64f505686ebf7bf6e1e80ecf59 This time I was better prepared (git was compiled with -g without optimization, the trap was commented out in git-clone, "ulimit -c" set to unlimited), and I attached gdb to git-http-fetch. Program received signal SIGSEGV, Segmentation fault. 0x00000000004044dc in closedown_active_slot (slot=0x656854202a200a73) at http.c:434 434 slot->in_use = 0; (gdb) p slot $1 = (struct active_request_slot *) 0x656854202a200a73 (gdb) p slot->in_use Cannot access memory at address 0x656854202a200a83 (gdb) where #0 0x00000000004044dc in closedown_active_slot (slot=0x656854202a200a73) at http.c:434 #1 0x00000000004044fa in release_active_slot (slot=0x656854202a200a73) at http.c:439 #2 0x00000000004070fc in abort_object_request (obj_req=0xdaf2b0) at http-fetch.c:1060 #3 0x00000000004071cf in fetch_object (repo=0x548f50, sha1=0xcd4838 "ñ¿¥\025×Ûþ¥c'\210æË©\213Ö}Ûôü") at http-fetch.c:1078 #4 0x00000000004073ed in fetch (sha1=0xcd4838 "ñ¿¥\025×Ûþ¥c'\210æË©\213Ö}Ûôü") at http-fetch.c:1126 #5 0x0000000000403126 in loop () at fetch.c:180 #6 0x000000000040336a in pull (target=0x7fff0c2e38c2 "heads/master") at fetch.c:248 #7 0x0000000000407a14 in main (argc=7, argv=0x7fff0c2e18a8) at http-fetch.c:1271 (gdb) It's a different backtrace this time. abort_object_request() has this code: if (obj_req->slot) { release_active_slot(obj_req->slot); obj_req->slot = NULL; } Apparently just because obj_req->slot is not NULL doesn't mean it's a valid pointer. I'm going to use Valgrind now. It's x86_64, FC5, Linux kernel from git. > I just posted a fix for the compile errors. As noted there, I've done > very little testing of the fetch/push binaries when built with > USE_CURL_MULTI commented out. Thank you. I'll try it too. -- Regards, Pavel Roskin - : 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