From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1657 invoked by alias); 25 Oct 2015 18:55:22 -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: 36965 Received: (qmail 26031 invoked from network); 25 Oct 2015 18:55:21 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Originating-IP: [86.6.158.222] X-Spam: 0 X-Authority: v=2.1 cv=UKUgZ3ry c=1 sm=1 tr=0 a=2SBOh4l1h08DI0L+aujZyQ==:117 a=2SBOh4l1h08DI0L+aujZyQ==:17 a=NLZqzBF-AAAA:8 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=R_2Yd4dMFm229QO15EgA:9 a=CjuIK1q_8ugA:10 Date: Sun, 25 Oct 2015 18:55:18 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: segfault in mkundoent when completing Message-ID: <20151025185518.43a8dde6@ntlworld.com> In-Reply-To: <151025095136.ZM29675@torch.brasslantern.com> References: <874mhfe8ng.fsf@djcbsoftware.nl> <151025095136.ZM29675@torch.brasslantern.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 25 Oct 2015 09:51:36 -0700 Bart Schaefer wrote: > On Oct 25, 8:59am, Dirk-Jan C. Binnema wrote: > } > } #0 __wmemcmp_sse4_1 () at ../sysdeps/x86_64/multiarch/memcmp-sse4.S:808 > } #1 0x00007fffeff1772c in mkundoent () at zle_utils.c:1510 > } #2 0x00007fffeff17be9 in get_undo_current_change (pm=) at zle_utils.c:1743 > } #3 0x00005555555be73a in export_param () > > This stack trace is at least missing a couple of steps if not trashed; > there's no path from export_param() to get_undo_current_change(). > > Assuming that at the very least the line number in mkundoent() is the > right one, something is giving wmemcmp() indigestion. When you say > this error is "fully reproducible", could you please tell us what the > steps are to reproduce it? Hmm... the change in question adds mkundoent() in a different context. I'm wondering if that UNMETACHECK() just above the crash might go off if this were copmiled with --enable-zsh-debug. But I couldn't get this to happen easily myself, even adding an extra DPUTS(). > I'm inclined to suspect something about the directory in which are you > completing file names is significant, possibly that a file name in the > directory contains bytes that don't form valid characters in the locale > being used by wmemcmp(), or some other unusual condition. The other > possiblity is one of the global (in C) variables lastline or zleline > being NULL or otherwise invalid. That would be the latter case, but then it's strange no one else has seen this, in which case the former seems more likely. pws