git problems

[Eygene Ryabinkin]

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/libc.so.7
(gdb) bt
#0  0x4841de8b in free () from /lib/libc.so.7
#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/libc.so.7
#4  0x4842199a in exit () from /lib/libc.so.7
#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.
-- 
Eygene