git problems

Chuck Robey chuckr at
Wed Jun 4 14:44:15 UTC 2008

Hash: SHA1

Eygene Ryabinkin wrote:
> Chuck,
> Wed, Jun 04, 2008 at 10:12:55AM -0400, Chuck Robey wrote:
>>>> I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace
>>>> nearby, but it seems to be crash inside free().
>>> Application memory errors in HEAD but not in a RELENG_ branch are
>>> frequently a symptom of an application bug unmasked by malloc(3)
>>> debugging enabled in the development branch but not production
>>> branches.  It might not hurt to ramp up debugging on your 6.x install to
>>> see if it starts crashing there was well -- see malloc(3) for details,
>>> you'll want to create an appropriate malloc.conf.
>> I didn't see the email where Ed Schouten commented about seeing my problems of
>> seeing no good stack frames, but Robert, I run only -current here, not RELENG_6,
>> so I can't do the testing you speak of.
> There is no need: I had tried this on -STABLE with environment
> variable MALLOC_OPTIONS set to 'J' -- it dumps core.  The problem
> seems to be in the git-fetch:
> -----
> $ MALLOC_OPTIONS=JA git-fetch --update-head-ok
> Segmentation fault: 11 (core dumped)
> -----
> This happens inside git repository of xserver and 100% reproducible
> for my both -CURRENT and -STABLE.
>> I would want to see if maybe our gcc on
>> - -current might have been made with a default of emitting no stack frames, which
>> I would guess might have this effect.
> The stack seems to be smashed at the second call to
> 'transport_unlock_pack': the argument called 'transport' seems to
> carry the pointer to the area, filled by malloc() with byte 0x5a:
> -----
> $ MALLOC_OPTIONS=JA gdb git-fetch
> 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"...
> (gdb) run --update-head-ok
> Starting program: /usr/local/bin/git-fetch --update-head-ok
> Program received signal SIGSEGV, Segmentation fault.
> 0x4841de8b in free () from /lib/
> (gdb) bt
> #0  0x4841de8b in free () from /lib/
> #1  0x080d8d04 in transport_unlock_pack (transport=0x820a0a0)
>     at transport.c:811
> #2  0x08066927 in unlock_pack () at builtin-fetch.c:56
> #3  0x48468fe3 in __cxa_finalize () from /lib/
> #4  0x4842199a in exit () from /lib/
> #5  0x0804b15b in handle_internal_command (argc=2, argv=0xffffffff)
>     at git.c:379
> #6  0x0804b8be in main (argc=2, argv=Error accessing memory address 0x10: Bad address.
> ) at git.c:414
> (gdb) fr 1
> #1  0x080d8d04 in transport_unlock_pack (transport=0x820a0a0)
>     at transport.c:811
> 811                     free(transport->pack_lockfile);
> (gdb) print *transport
> $1 = {remote = 0x5a5a5a5a,
>   url = 0x5a5a5a5a <Error reading address 0x5a5a5a5a: Bad address>,
>   data = 0x5a5a5a5a, remote_refs = 0x5a5a5a5a, set_option = 0x5a5a5a5a,
>   get_refs_list = 0x5a5a5a5a, fetch = 0x5a5a5a5a, push = 0x5a5a5a5a,
>   disconnect = 0x5a5a5a5a,
>   pack_lockfile = 0x5a5a5a5a <Error reading address 0x5a5a5a5a: Bad address>,
>   verbose = -2}
> (gdb)
> -----
> I don't believe that __cxa_finalize should call unlock_pack, so
> stack seems to be smashed somewhere before.
>> I guess I could test this, and if it's so, recompile all my libraries to undo
>> that, because I abhor doing things that utterly block any troubleshooting at a
>> minimal savings elsewhere.
> You don't need to recompile anything to enable malloc debugging.
> The easiest way is to set MALLOC_OPTIONS to the needed malloc
> flags.

Good, that's what I'd figured on my own.  I may be slow as mollasses, but I'm
more than a little stubborn, I will track this down (if no one else beats me to
it).  I really need my git to work here.

Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla -


More information about the freebsd-hackers mailing list