Re: BUG: coredump with menu-select and LIST_PACKED

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Oct 26, 11:17am, Sven Wischnowsky wrote:
} Subject: Re: BUG: coredump with menu-select and LIST_PACKED
}
} Bart Schaefer wrote:
} 
} > On Oct 25,  8:06pm, Alexandre Duret-Lutz wrote:
} > } Subject: BUG: coredump with menu-select and LIST_PACKED
} > }
} > } venus% setopt listpacked
} > } venus% foo <TAB>
} > } 1      11     13     15     3     5     7     9                 
} > } 10     12     14     2      4     6     8     xxxxxxxxxxxxxxx   
} > } venus% foo <M-m>
} > } zsh: segmentation fault (core dumped)  zsh -f
} > 
} > Looks like the `amatches' global is garbage.  Here's a stack trace (this is
} > after patches 8412 and 8413).
} > 
} > #0  0x4013c377 in clprintm (g=0x80d8168, mp=0x80c2b00, mc=0, ml=0, lastc=0, 
} >     width=135800832, path=0x80d1ab0 "./1", buf=0xbffff0d8)
} >     at ../../../zsh-3.1.6/Src/Zle/complist.c:390
} 
} Hm. I can't reproduce this bug and my line complist.c:390 doesn't
} access `amatches'.

It does, but very indirectly.  That line is (was, before your huge patch;
I don't know yet now):

	    for (i = (width ? width : mcols); i--; ) {
390		mtab[mx + mm + i] = mp;
		mgtab[mx + mm + i] = g;
	    }

The value of `i' comes from `width' which comes a few call frames up from
`amatches->width', which is trash (a huge number).

} So I have to ask: can someone tell me how to reproduce this with a
} `zsh -f'?

The instructions that Alexandre gave were exactly what I did to produce
the stack trace.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com