git

[Giorgos Keramidas]

On Tue, 03 Jun 2008 14:31:24 -0400, Chuck Robey <chuckr at telenix.org> 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 at kobe:/home/keramida/git/erc$ git fetch
  Segmentation fault: 11 (core dumped)
  keramida at 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 at kobe:/home/keramida$ cd git/erc
: keramida at kobe:/home/keramida/git/erc$ git-fetch
: Segmentation fault: 11 (core dumped)
: keramida at 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 at kobe:/home/keramida$ ls -l /etc/malloc*
  lrwxr-xr-x  1 root  wheel  - 2 Mar 28 19:31 /etc/malloc.conf -> AJ
  keramida at 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