bindkey induced coredump

bindkey induced coredump

[Mark Hanson]

$ zsh -f
$ echo $ZSH_VERSION
3.0.0
$ bindkey -v
$ bindkey -r '\e[A'
$ bindkey -r '\e[B'
$ bindkey -r '\e[C'
$ bindkey -r '\e[D'
$ <ESC><ESC>
coredump

Here's a stacktrace:

#0  0x7ef80 in getkeycmd () at zle_main.c:528
528             if ((cky = (Key) keybindtab->getnode(keybindtab, keybuf))->func == z_undefinedkey)
(gdb) bt
#0  0x7ef80 in getkeycmd () at zle_main.c:528
#1  0x7e79c in zleread (
    lp=0xc2fc0 "%{\e[33m%}1:%n@%m:%!%#%{\e[36m%} %{\e[32m%}", 
    rp=0xc3f10 "%{\e[35m%}%~%{\e[32m%}") at zle_main.c:431
#2  0x402d0 in inputline () at input.c:264
#3  0x400fc in ingetc () at input.c:220
#4  0x36340 in hgetc () at hist.c:109
#5  0x455f4 in gettok () at lex.c:375
#6  0x44c50 in yylex () at lex.c:185
#7  0x5a024 in parse_event () at parse.c:59
#8  0x3d32c in loop (toplevel=1) at init.c:115
#9  0x3d118 in main (argc=2, argv=0xf7fff48c) at init.c:74

I put the "bindkey -r"'s in there to keep zsh from waiting to see if it
had an escape key or not.  The lag throws me off, but if there aren't
any other keys bound to an escape sequence, the lag goes away.  If you
need more information, let me know.

Thanks,
Mark

Re: bindkey induced coredump

[Zefram]

>$ bindkey -v
>$ bindkey -r '\e[A'
>$ bindkey -r '\e[B'
>$ bindkey -r '\e[C'
>$ bindkey -r '\e[D'
>$ <ESC><ESC>
>coredump

Multi-character bindings don't work properly in some cases -- changing
a key to or from being a prefix.

-zefram

Re: bindkey induced coredump

[Peter Stephenson]

Mark Hanson wrote:
> $ zsh -f
> $ echo $ZSH_VERSION
> 3.0.0
> $ bindkey -v
> $ bindkey -r '\e[A'
> $ bindkey -r '\e[B'
> $ bindkey -r '\e[C'
> $ bindkey -r '\e[D'
> $ <ESC><ESC>
> coredump

Doesn't look like anybody else has had a go at this.

I think the following patch is right, but this had me confused for a
long time.  The confusion is all the different key binding tables.  I
think what's happening is this:  the last bindkey -r deletes the entry
for "\e" in keybindtab (which is vikeybindtab) since it now has
nothing attached to it in mainbindtab.  However it is still marked as
a prefix in altbindtab, which is used in vi command mode, which is
what the first <ESC> enters.  Hence the crash when zle tries to look
for a key representing the prefix on the second <ESC>.  (keybindtab,
as I understand it, is only used to resolve multi-key sequences and
the like.)

The answer seems to be to make sure the prefix entry is deleted in the
other bindtab.  It's not actually clear that one wants to remove all
those cursor key entries in the alternate keymap, but given there is
only one keybindtab for vi mode, that's currently inevitable.

The remaining question is what to set the key to in the other bindtab,
given that it was previously only set for a prefix.  The choices are
undefined or the same as in the first bindtab.  I picked the latter.

*** Src/zle_main.c.bind	Thu Sep  5 22:47:12 1996
--- Src/zle_main.c	Thu Sep 12 13:37:02 1996
***************
*** 991,997 ****
--- 991,1005 ----
  			}
  			(ky = (Key) keybindtab->getnode(keybindtab, s))->prefixct--;
  			if (!ky->prefixct) {
+ 			    int *otab = ops['a'] ? mainbindtab : altbindtab;
  			    tab[STOUC(*s)] = ky->func;
+ 			    /*
+ 			     * If the bindtab we are not using also
+ 			     * adds this key as a prefix, it must also
+ 			     * be reset.
+ 			     */
+ 			    if (otab[STOUC(*s)] == z_prefix)
+ 				otab[STOUC(*s)] = ky->func;
  			    if (ky->func != z_sendstring)
  				free(keybindtab->removenode(keybindtab, s));
  			}

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77330
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.