From owner-freebsd-questions@FreeBSD.ORG Wed Jun 4 01:22:36 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3603C1065671 for ; Wed, 4 Jun 2008 01:22:36 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 9E93B8FC0A for ; Wed, 4 Jun 2008 01:22:35 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl138-114.kln.forthnet.gr [77.49.9.114]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-4) with ESMTP id m541MBk2013516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jun 2008 04:22:30 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m541MBMY005541; Wed, 4 Jun 2008 04:22:11 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m541MAWo005540; Wed, 4 Jun 2008 04:22:10 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Chuck Robey References: <48458DFC.9020004@telenix.org> Date: Wed, 04 Jun 2008 04:22:09 +0300 In-Reply-To: <48458DFC.9020004@telenix.org> (Chuck Robey's message of "Tue, 03 Jun 2008 14:31:24 -0400") Message-ID: <87y75m3sfy.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: m541MBk2013516 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.759, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.64, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: FreeBSD Questions Mailing List Subject: Re: git X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2008 01:22:36 -0000 On Tue, 03 Jun 2008 14:31:24 -0400, Chuck Robey wrote: > Wonder if anyone could tell me why anything I do to run git-pull gives me a > coredump? The image that gets dumped is git-fetch, if that helps, and I was > just trying to update the xorg source tree. Hi Chuck, Something is obviously broken in Git 1.5.5. My installation from Ports core dumps pretty fast too: keramida@kobe:/home/keramida/git/erc$ git fetch Segmentation fault: 11 (core dumped) keramida@kobe:/home/keramida/git/erc$ I have a kernel+userland compiled with debugging symbols, and this seems to be a double-free bug in git-fetch(1): : keramida@kobe:/home/keramida$ cd git/erc : keramida@kobe:/home/keramida/git/erc$ git-fetch : Segmentation fault: 11 (core dumped) : keramida@kobe:/home/keramida/git/erc$ gdb /usr/local/bin/git-fetch git-fetch.core : GNU gdb 6.1.1 [FreeBSD] : Copyright 2004 Free Software Foundation, Inc. : GDB is free software, covered by the GNU General Public License, and you are : welcome to change it and/or distribute copies of it under certain conditions. : Type "show copying" to see the conditions. : There is absolutely no warranty for GDB. Type "show warranty" for details. : This GDB was configured as "i386-marcel-freebsd"...No symbol table is loaded. Use the "file" command. : : Core was generated by `git-fetch'. : Program terminated with signal 11, Segmentation fault. : Reading symbols from /usr/local/lib/libcurl.so.4...done. : Loaded symbols for /usr/local/lib/libcurl.so.4 : Reading symbols from /lib/libz.so.4...done. : Loaded symbols for /lib/libz.so.4 : Reading symbols from /usr/local/lib/libiconv.so.3...done. : Loaded symbols for /usr/local/lib/libiconv.so.3 : Reading symbols from /lib/libcrypto.so.5...done. : Loaded symbols for /lib/libcrypto.so.5 : Reading symbols from /lib/libc.so.7...done. : Loaded symbols for /lib/libc.so.7 : Reading symbols from /usr/lib/libssl.so.5...done. : Loaded symbols for /usr/lib/libssl.so.5 : Reading symbols from /libexec/ld-elf.so.1...done. : Loaded symbols for /libexec/ld-elf.so.1 : #0 idalloc (ptr=0x5a5a5a5a) at /home/build/src/lib/libc/stdlib/malloc.c:3386 : 3386 arena_dalloc(chunk->arena, chunk, ptr); : (gdb) bt : #0 idalloc (ptr=0x5a5a5a5a) at /home/build/src/lib/libc/stdlib/malloc.c:3386 : #1 0x28441357 in free (ptr=0x5a5a5a5a) at /home/build/src/lib/libc/stdlib/malloc.c:4714 : #2 0x080d7a54 in transport_unlock_pack () : #3 0x080667f7 in unlock_pack () : #4 0x28495af3 in __cxa_finalize (dso=0x0) at /home/build/src/lib/libc/stdlib/atexit.c:180 : #5 0x2844549a in exit (status=0) at /home/build/src/lib/libc/stdlib/exit.c:67 : #6 0x0804b15d in handle_internal_command () : #7 0x0804b88d in main () : (gdb) quit Note the 0x5a5a5a5a pointer value in free(). That's a bug in git-fetch. A double free() that our malloc uncovers. This is a double-free() because I'm running my laptop with: keramida@kobe:/home/keramida$ ls -l /etc/malloc* lrwxr-xr-x 1 root wheel - 2 Mar 28 19:31 /etc/malloc.conf -> AJ keramida@kobe:/home/keramida$ and 'J' enables the following malloc()/free() behavior: Each byte of new memory allocated by malloc(), realloc() or reallocf() will be initialized to 0xa5. All memory returned by free(), realloc() or reallocf() will be initialized to 0x5a. This is intended for debugging and will impact performance negatively. Are you also running with option 'J' enabled in `malloc.conf'? HTH, Giorgos