Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: segfault in mkundoent when completing

On Sun, 25 Oct 2015 09:51:36 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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=<optimized out>) 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.


Messages sorted by: Reverse Date, Date, Thread, Author