Re: git master describe segfault

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Daniel Stenberg <daniel@xxxxxxx> writes:

> 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.
 


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]