Re: git master describe segfault

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 21, 2016, 19:31 UTC
Message-ID: <xmqqzitrljaz.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.20.1603211025330.20859@tvnag.unkk.fr>

Daniel Stenberg <daniel@haxx.se> writes:

Show 36 quoted lines

> 0. I'm on a Linux box: a reasonably updated Debian unstable.
>
> 1. I'm up to date with the latest git master branch of gecko-dev:
> https://github.com/mozilla/gecko-dev (counting a little over 467K
> commits)
>
> 2. I built the current git off the master branch (v2.8.0-rc3-12-g047057b)
>
> 3. In the gecko-dev dir, I run 'git describe --contains f495d0cc2'
>
> The outcome is what looks like a fine stack smash due to very very
> extensive recursion:
>
> $ gdb --args ../git/git describe --contains f495d0cc2
> (gdb) run
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff7bccf73 in ?? () from /lib/x86_64-linux-gnu/libz.so.1
> ...
> #12 0x0000000000464662 in name_rev (commit=0x170df20,
> tip_name=0x8e9170 "B2G_1_0_0_20130115070201", generation=87254,
> distance=87254, deref=0) at builtin/name-rev.c:30
> #13 0x00000000004647de in name_rev (commit=0x170dee0,
> tip_name=0x8e9170 "B2G_1_0_0_20130115070201", generation=87253,
> distance=87253, deref=0) at builtin/name-rev.c:72
> #14 0x00000000004647de in name_rev (commit=0x170dea0,
> tip_name=0x8e9170 "B2G_1_0_0_20130115070201", generation=87252,
> distance=87252, deref=0) at builtin/name-rev.c:72
> #15 0x00000000004647de in name_rev (commit=0x170de60,
> tip_name=0x8e9170 "B2G_1_0_0_20130115070201", generation=87251,
> distance=87251, deref=0) at builtin/name-rev.c:72
> #16 0x00000000004647de in name_rev (commit=0x170de20,
> tip_name=0x8e9170 "B2G_1_0_0_20130115070201", generation=87250,
> distance=87250, deref=0) at builtin/name-rev.c:72
> #17 0x00000000004647de in name_rev (commit=0x170dde0,
> tip_name=0x8e9170 "B2G_1_0_0_20130115070201", generation=87249,
> distance=87249, deref=0) at builtin/name-rev.c:72

It does look bad.  name_rev() naively recurses quite a lot and
easily runs out of stack space, it seems (rewriting the recursion
to iterative implementation may help).  I haven't looked at this
code carefully for quite a while, but I suspect piece of memory
pointed at by new_name variable may also be leaking.