Re: segfault in mkundoent when completing

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

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.

pws