Date: Wed, 04 Jun 2008 10:34:46 -0400 From: Chuck Robey <chuckr@telenix.org> To: Eygene Ryabinkin <rea-fbsd@codelabs.ru> Cc: Ed Schouten <ed@80386.nl>, Robert Watson <rwatson@FreeBSD.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: git problems Message-ID: <4846A806.9040204@telenix.org> In-Reply-To: <7tA3MvVpZ14HTFbKQUoucxMjR6I@XW7GVEPlMa2oCuO15y8lYU4QCgM> References: <4845AC84.6040407@telenix.org> <20080603212355.GB64397@hoeg.nl> <20080604134830.D49920@fledge.watson.org> <4846A2E7.2060003@telenix.org> <7tA3MvVpZ14HTFbKQUoucxMjR6I@XW7GVEPlMa2oCuO15y8lYU4QCgM>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
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/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.
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIRqgGz62J6PPcoOkRAs0nAJ0YK0+z9uoUn4Ja97ZG/UECj1OLGgCfffBj
NLCk9xbUINso5d+5QohpefQ=
=slbH
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4846A806.9040204>