segfault in mkundoent when completing

segfault in mkundoent when completing

[Dirk-Jan C. Binnema]

I'm seeing a fully reproducible segfault when completing, e.g. "ls
<TAB>" with zsh version 5.1.1, which is the version that comes with
Fedora 23.

Sourceforge won't let me file a ticket there, so sending it here.

Program received signal SIGSEGV, Segmentation fault.
__wmemcmp_sse4_1 () at ../sysdeps/x86_64/multiarch/memcmp-sse4.S:808
808		mov	-12(%rsi), %rcx
gdb% bt
#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 ()
#4  0x00005555555bf3f8 in unsetparam_pm ()
#5  0x00005555555944a4 in scanmatchtable ()
#6  0x0000555555594667 in scanhashtable ()
#7  0x00005555555c1f16 in endparamscope ()
#8  0x0000555555589678 in runshfunc ()
#9  0x00007fffef6b21dc in comp_wrapper (prog=0x5555558bedc0, w=0x0, name=0x7ffff7fe8038 "_main_complete") at complete.c:1459
#10 0x00005555555895e1 in runshfunc ()

A kind soul on #zsh helped to find the commit that triggered this, it's
this one:
  https://sourceforge.net/p/zsh/code/ci/832130c57dedc532191512045096180657a049f3/
and indeed going back to the revision before that one makes the problem
go away.

Cheers,
Dirk.

-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl           w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C

Re: segfault in mkundoent when completing

[Bart Schaefer]

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?

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.

Re: segfault in mkundoent when completing

[Peter Stephenson]

On Sun, 25 Oct 2015 09:51:36 -0700
Bart Schaefer <schaefer@brasslantern.com> 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