Segfault with terminal width <= 6

[Roman Perepelitsa <roman.perepelitsa@gmail.com>]

When terminal width is <= 6, there is memory corruption somewhere that
leads to segfault. It reproduces reliably on my machine with the
following sequence.

1. Resize your terminal to 6x6. Height doesn't matter but it's
important for width to be <= 6.

2. Type `PROMPT='' zsh -df`. The value of PROMPT doesn't matter. I'm
using empty propt so that my "screenshots" look the same as what you
would see if you attempted to reproduce this.

3. Press and hold `x` until you see `>` appearing on the first line.
It doesn't matter if you hold it longer than necessary.

    >....
    xxxxxx
    xxxxxx
    xxxxxx
    xxxxxx

4. Press and hold left arrow until `>` disappears. It doesn't matter
if you hold it longer than necessary.

    xxxxxx
    xxxxxx
    xxxxxx
    xxxxxx
    xxxxxx
    <....

5. At this point memory is corrupted and many actions can crash zsh.
The simplest is to press Ctrl+C.

    free(): invalid next size (fast)
    zsh: abort (core dumped)

Here's a backtrace:

    #0  __GI_raise (sig=sig@entry=6)
        at ../sysdeps/unix/sysv/linux/raise.c:51
    #1  0x00007f8dcba57801 in __GI_abort () at abort.c:79
    #2  0x00007f8dcbaa0897 in __libc_message (
        action=action@entry=do_abort,
        fmt=fmt@entry=0x7f8dcbbcdb9a "%s\n")
        at ../sysdeps/posix/libc_fatal.c:181
    #3  0x00007f8dcbaa790a in malloc_printerr (
        str=str@entry=0x7f8dcbbcf800 "free(): invalid next size
(fast)") at malloc.c:5350
    #4  0x00007f8dcbaaef60 in _int_free (have_lock=0,
        p=0x55f7fcc5f1b0, av=0x7f8dcbe02c40 <main_arena>)
        at malloc.c:4213
    #5  __GI___libc_free (mem=0x55f7fcc5f1c0) at malloc.c:3124
    #6  0x00007f8dca3ce6e3 in freechanges (p=0x55f7fcc5f270)
        at zle_utils.c:1452
    #7  0x00007f8dca3ce65f in freeundo () at zle_utils.c:1436
    #8  0x00007f8dca3ad564 in zleread (lp=0x55f7fbcace20 <prompt>,
        rp=0x0, flags=3, context=0,
        init=0x7f8dca3d75c0 "zle-line-init",
        finish=0x7f8dca3d75b0 "zle-line-finish") at zle_main.c:1371
    #9  0x00007f8dca3b052b in zle_main_entry (cmd=1,
        ap=0x7ffe7fd8f620) at zle_main.c:2119
    #10 0x000055f7fba0a83c in zleentry (cmd=1) at init.c:1605
    #11 0x000055f7fba0bb8d in inputline () at input.c:295
    #12 0x000055f7fba0b9d1 in ingetc () at input.c:228
    #13 0x000055f7fb9fd945 in ihgetc () at hist.c:408
    #14 0x000055f7fba15e99 in gettok () at lex.c:611
    #15 0x000055f7fba15576 in zshlex () at lex.c:275
    #16 0x000055f7fba3d3b0 in parse_event (endtok=37) at parse.c:581
    #17 0x000055f7fba0695e in loop (toplevel=1, justonce=0)
        at init.c:150
    #18 0x000055f7fba0ad38 in zsh_main (argc=2, argv=0x7ffe7fd8fae8)
        at init.c:1770
    #19 0x000055f7fb9bc0b7 in main (argc=2, argv=0x7ffe7fd8fae8)
        at ./main.c:93

If you do something different on step 5, it'll crash with a different
stack trace. All stack traces I've seen lead to __GI___libc_free.

This appears to be an old bug. zsh-4.3.17 crashes in the same manner.
I haven't tried it with an older version.

Roman.