Hello good peeps!
I just ran head-first into a segfault that is fully reproducable for me but
I'm not at all fluent in these internals so I'm not the suitable person to
offer a fix. Let me instead offer you some fine details:
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
#0 0x00007ffff7bccf73 in ?? () from /lib/x86_64-linux-gnu/libz.so.1
#1 0x00007ffff7bcc233 in inflate () from /lib/x86_64-linux-gnu/libz.so.1
#2 0x00000000005935d6 in git_inflate (strm=0x7fffff7ff1d0, flush=4) at
zlib.c:118
#3 0x000000000055d2fd in unpack_compressed_entry (p=0x886b00,
w_curs=0x7fffff7ff8e8, curpos=83902121, size=242) at sha1_file.c:2087
#4 0x000000000055dcbb in unpack_entry (p=0x886b00, obj_offset=83902119,
final_type=0x7fffff7ffb50, final_size=0x7fffff7ffb48) at sha1_file.c:2341
#5 0x000000000055d533 in cache_or_unpack_entry (p=0x886b00,
base_offset=83902119, base_size=0x7fffff7ffb48, type=0x7fffff7ffb50,
keep_cache=1) at sha1_file.c:2165
#6 0x000000000055ed88 in read_packed_sha1 (sha1=0x170df24
"w\367\026,ũD\362\b4\001{\216\b[\255\261", <incomplete sequence \335>,
type=0x7fffff7ffb50, size=0x7fffff7ffb48) at sha1_file.c:2789
#7 0x000000000055f01b in read_object (sha1=0x170df24
"w\367\026,ũD\362\b4\001{\216\b[\255\261", <incomplete sequence \335>,
type=0x7fffff7ffb50, size=0x7fffff7ffb48) at sha1_file.c:2837
#8 0x000000000055f0f3 in read_sha1_file_extended (sha1=0x170df24
"w\367\026,ũD\362\b4\001{\216\b[\255\261", <incomplete sequence \335>,
type=0x7fffff7ffb50, size=0x7fffff7ffb48, flag=1) at sha1_file.c:2865
#9 0x00000000004b1e2b in read_sha1_file (sha1=0x170df24
"w\367\026,ũD\362\b4\001{\216\b[\255\261", <incomplete sequence \335>,
type=0x7fffff7ffb50, size=0x7fffff7ffb48) at cache.h:1008
#10 0x00000000004b2fc9 in parse_commit_gently (item=0x170df20,
quiet_on_missing=0) at commit.c:383
#11 0x0000000000464627 in parse_commit (item=0x170df20) at ./commit.h:65
#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
...
#35070 0x00000000004647de in name_rev (commit=0x1172250, tip_name=0x8e9170
"B2G_1_0_0_20130115070201", generation=52196, distance=52196, deref=0) at
builtin/name-rev.c:72
#35071 0x00000000004647de in name_rev (commit=0x1172210, tip_name=0x8e9170
"B2G_1_0_0_20130115070201", generation=52195, distance=52195, deref=0) at
builtin/name-rev.c:72
#35072 0x00000000004647de in name_rev (commit=0x11721d0, tip_name=0x8e9170
"B2G_1_0_0_20130115070201", generation=52194, distance=52194, deref=0) at
builtin/name-rev.c:72
...
and so on, I actually didn't bother to find the end of this but logically I'd
guess there was about 52194 more stack frames to go!
(gdb) fr 2
#2 0x00000000005935d6 in git_inflate (strm=0x7fffff7ff1d0, flush=4) at
zlib.c:118
118 status = inflate(&strm->z,
(gdb) list
113 int status;
114
115 for (;;) {
116 zlib_pre_call(strm);
117 /* Never say Z_FINISH unless we are feeding everything
*/
118 status = inflate(&strm->z,
119 (strm->z.avail_in != strm->avail_in)
120 ? 0 : flush);
121 if (status == Z_MEM_ERROR)
122 die("inflate: out of memory");
... and the 'strm' struct looks fine to a layman like me:
(gdb) p *strm
$2 = {z = {
next_in = 0x7fffb234bea9 "x\234\245\216\273\n\003!\020E{\277\302&U
8\263\352(\204\374\213\343\003\267\330U\304@>?n\237.\267<\\\016g\216\234%\030\353-%\364D\314X\210\302\226\031t\214\316C\304d\035\004\255\vZ\321\303\310\347\224T\b\301\220\211\224La&}\235\213\"`\334,+\214X\034{mDx\317چ\254}\204T\303y\253m\366\326\037\261\035\362\371\003\276$(G\236\064lV\336՚X\364\330\347\314\177ID\331?\362\062\255x\361\005\272qJ\206\225\022x\234\245\214\061n\304
\020", avail_in = 989839703, total_in = 0, next_out = 0x15d1920
"x+3\367\377\177", avail_out = 243, total_out = 0, msg = 0x0, state =
0x1728cd0, zalloc = 0x7ffff7bd0000, zfree = 0x7ffff7bd0010,
opaque = 0x0, data_type = 0, adler = 1, reserved = 0}, avail_in =
989839703, avail_out = 243, total_in = 0, total_out = 0,
next_in = 0x7fffb234bea9 "x\234\245\216\273\n\003!\020E{\277\302&U
8\263\352(\204\374\213\343\003\267\330U\304@>?n\237.\267<\\\016g\216\234%\030\353-%\364D\314X\210\302\226\031t\214\316C\304d\035\004\255\vZ\321\303\310\347\224T\b\301\220\211\224La&}\235\213\"`\334,+\214X\034{mDx\317چ\254}\204T\303y\253m\366\326\037\261\035\362\371\003\276$(G\236\064lV\336՚X\364\330\347\314\177ID\331?\362\062\255x\361\005\272qJ\206\225\022x\234\245\214\061n\304
\020", next_out = 0x15d1920 "x+3\367\377\177"}
Let me know what else I can do to help anyone figure this out!
--
/ daniel.haxx.se
