From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6899 invoked by alias); 13 Aug 2010 15:57:29 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 28166 Received: (qmail 28736 invoked from network); 13 Aug 2010 15:57:27 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <100813085709.ZM22377@torch.brasslantern.com> Date: Fri, 13 Aug 2010 08:57:08 -0700 In-reply-to: <20100813080811.GB495@ph> Comments: In reply to Philipp Hartwig "Re: segfault on menu-select" (Aug 13, 10:08am) References: <20100812144626.GI28144@ph> <8762zf6fwo.fsf@ft.bewatermyfriend.org> <20100812152044.GJ28144@ph> <87wrrv4yrg.fsf@ft.bewatermyfriend.org> <20100812165307.GA24998@ph> <87r5i34v51.fsf@ft.bewatermyfriend.org> <20100812173356.GC24998@ph> <100812160702.ZM20648@torch.brasslantern.com> <20100813080811.GB495@ph> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers mailing list Subject: Re: segfault on menu-select MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable On Aug 13, 10:08am, Philipp Hartwig wrote: } } Note that in order to reproduce the issue it really seems to be=20 } necessary to have the 4 lines }=20 } autoload -Uz compinit } compinit } zmodload -i zsh/complist } bindkey '^o' menu-select }=20 } in your .zshrc. Just typing them or sourcing a file containing them will= =20 } not lead to the crash in my case, even without the "-f" option. Hmm, indeed. I'm finally able to reproduce this. It's also necessary to have invoked completion once before trying menu-select, just hitting ^o won't do it (in fact, won't do *anything*, which is slightly suspicious). The more direct symptom is that there's garbage in minfo.group->matches ("minfo" is a global). I tried putting a watchpoint on minfo.group but because matches is a pointer that's not very helpful; all I determined is that it's last assigned here: Hardware watchpoint 1: minfo.group Old value =3D 0x8853ea8 New value =3D 0x8872690 0x08103002 in do_allmatches (end=3D0) at ../../../zsh-4.0/Src/Zle/compresult.c:902 902 for (minfo.group =3D amatches; At which point the contents of ->matches look like this: (gdb) p m $6 =3D 0x8d1efa8 (gdb) p *m $7 =3D {str =3D 0x0, orig =3D 0x21
,=20 ipre =3D 0x886fcf8 "",=20 ripre =3D 0x8b6870 "(=B7=D4\b@\031\205\b=A8=EF=D1\b\230\032\207\b =D4=D4\b\210=F5\206\b=A0\211=D2\b=A0e=CF\b=A0m=D4\b0=FB=D1\b8o=CF\b(n=CF\b= =B0=E9=D2\bh=C6=D3\b@`=D4\b@`=D4\b=A8<\205\b=A8<\205\b\b|\206\b=B8=C2\204\b= =B8h\213", isuf =3D 0x5f73756f
,=20 ppre =3D 0x69736f70
,=20 psuf =3D 0x6e6f6974
, prpre =3D 0x8d100= 73 "",=20 pre =3D 0x20
,=20 suf =3D 0x10
,=20 disp =3D 0x6d75645f
,=20 autoq =3D 0x6d646170
, flags =3D 0,=20 brpl =3D 0x19, brsl =3D 0x0, rems =3D 0x8d23720 "dmeventd", remf =3D 0x0,= =20 qipl =3D 142976480, qisl =3D 0, rnum =3D 17, gnum =3D 7173740, mode =3D 9= 136216,=20 modec =3D 0 '\0', fmode =3D 25, fmodec =3D -112 '\220'} However, the crash doesn't always happen that deep in the call stack; having the hardware watchpoint present changes the behavior a bit, so I suspect *amatches has already been messed up for a while at this point. Unfortunately I'm out of time to poke at it just now. --=20