bindkey <whatever> history-beginning-search-backwards; echo $widgts = crash

bindkey <whatever> history-beginning-search-backwards; echo $widgts = crash

[Maddi Kopfermann]

Hi Zsh Comrades,

Yesterday i found what it seems to be a very old bug.

bindkey <whatever> history-beginning-search-backwards &&
echo $widgets crashes zsh, it does with zsh -f.
On #zsh Frank Terbeck had it crash even with 3.1.7. All
versions that have history-beginning-search-backwards did
crash, it seems.

gdb zsh core has:

        Program terminated with signal 11, Segmentation
        fault.
        #0  widgetstr (w=0x0) at
        ../../../Src/Zle/zleparameter.c:78
        78      ../../../Src/Zle/zleparameter.c: No such
        file or directory.
                in ../../../Src/Zle/zleparameter.c


                Greetings,
                        Matthias

PS: This is a resent because I sadly posted the email not as a new thread

Re: bindkey <whatever> history-beginning-search-backwards; echo $widgts = crash

[Phil Pennock]

[-- Attachment #1: Type: text/plain, Size: 2879 bytes --]

On 2007-05-21 at 22:21 +0200, Maddi Kopfermann wrote:
> Hi Zsh Comrades,
> 
> Yesterday i found what it seems to be a very old bug.
> 
> bindkey <whatever> history-beginning-search-backwards &&

history-beginning-search-backwards is not a standard widget; aside from
this bug, you need to find which widget you really want.

> echo $widgets crashes zsh, it does with zsh -f.
> On #zsh Frank Terbeck had it crash even with 3.1.7. All
> versions that have history-beginning-search-backwards did
> crash, it seems.

This is a bug when there is no widget with the supplied name; the value
for the type can't be calculated.  The code which loops over the widgets
doesn't notice that the widget doesn't really exist and the code which
produces a stringification doesn't handle it.

% bindkey '^Z' fred
% ^Z
No such widget `fred'
% print ${(v)widgets}
[segfault]

The attached patch ensures that there's an appropriate value for the
key; it'll do as a work-around for now.

#0  0x0000000801918291 in widgetstr (w=0x0) at zleparameter.c:78
78          if (w->flags & WIDGET_INT)
(gdb) bt
#0  0x0000000801918291 in widgetstr (w=0x0) at zleparameter.c:78
#1  0x00000008019184f8 in scanpmwidgets (ht=0x55cd40, func=0x80069a6d0 <scanparamvals>, flags=1) at zleparameter.c:134
#2  0x000000080067229f in scanmatchtable (ht=0x55cd40, pprog=0x0, sorted=0, flags1=0, flags2=33554432, 
    scanfunc=0x80069a6d0 <scanparamvals>, scanflags=1) at hashtable.c:381
#3  0x000000080067258b in scanhashtable (ht=0x55cd40, sorted=0, flags1=0, flags2=33554432, scanfunc=0x80069a6d0 <scanparamvals>, 
    scanflags=1) at hashtable.c:444
#4  0x000000080069a959 in paramvalarr (ht=0x55cd40, flags=1) at params.c:547
#5  0x000000080069aa25 in getvaluearr (v=0x7fffffffdf40) at params.c:565
#6  0x000000080069e409 in getarrvalue (v=0x7fffffffdf40) at params.c:1862
#7  0x00000008006bda52 in paramsubst (l=0x545068, n=0x545098, str=0x7fffffffe088, qt=0, ssub=0) at subst.c:2034
#8  0x00000008006b9afa in stringsubst (list=0x545068, node=0x545098, ssub=0, asssub=0) at subst.c:193
#9  0x00000008006b9400 in prefork (list=0x545068, flags=0) at subst.c:91
#10 0x0000000800664304 in execcmd (state=0x7fffffffe650, input=0, output=0, how=18, last1=2) at exec.c:2039
#11 0x000000080066253e in execpline2 (state=0x7fffffffe650, pcode=387, how=18, input=0, output=0, last1=0) at exec.c:1343
#12 0x000000080066199c in execpline (state=0x7fffffffe650, slcode=4098, how=18, last1=0) at exec.c:1129
#13 0x0000000800661261 in execlist (state=0x7fffffffe650, dont_change_job=0, exiting=0) at exec.c:935
#14 0x0000000800660dda in execode (p=0x544f68, dont_change_job=0, exiting=0) at exec.c:793
#15 0x000000080067bd5c in loop (toplevel=1, justonce=0) at init.c:180
#16 0x000000080067ede0 in zsh_main (argc=1, argv=0x7fffffffe780) at init.c:1347
#17 0x00000000004006cb in main (argc=1, argv=0x7fffffffe780) at ./main.c:93

-Phil

[-- Attachment #2: widget-crash.patch --]
[-- Type: text/x-diff, Size: 457 bytes --]

diff -urp zsh-head/Src/Zle/zleparameter.c zsh-bindkey-crash/Src/Zle/zleparameter.c
--- zsh-head/Src/Zle/zleparameter.c	Tue Mar  7 13:31:44 2006
+++ zsh-bindkey-crash/Src/Zle/zleparameter.c	Mon May 21 18:37:22 2007
@@ -75,6 +75,8 @@ createspecialhash(char *name, GetNodeFun
 static char *
 widgetstr(Widget w)
 {
+    if (!w)
+	return dupstring("undefined");
     if (w->flags & WIDGET_INT)
 	return dupstring("builtin");
     if (w->flags & WIDGET_NCOMP) {

Re: bindkey <whatever> history-beginning-search-backwards; echo $widgts = crash

[Phil Pennock]

[-- Attachment #1: Type: text/plain, Size: 843 bytes --]

On 2007-05-21 at 18:46 -0700, Phil Pennock wrote:
> This is a bug when there is no widget with the supplied name; the value
> for the type can't be calculated.  The code which loops over the widgets
> doesn't notice that the widget doesn't really exist and the code which
> produces a stringification doesn't handle it.

Is it better for the $widgets associative array to pretend that such a
key doesn't exist, or to acknowledge that it does exist with undefined
value?

Previous patch implemented the latter.

This patch implements the former, keeping the "undefined" fallback
around just in case there's another bug.

Intuitively, the $widgets array shouldn't pretend that nodes don't
exist, but then there's conflicting behaviour with getpmwidgets() which
returns an empty string.

I leave the decision to those with more experience.
-Phil

[-- Attachment #2: widget-crash2.patch --]
[-- Type: text/x-diff, Size: 782 bytes --]

diff -urp zsh-head/Src/Zle/zleparameter.c zsh-bindkey-crash/Src/Zle/zleparameter.c
--- zsh-head/Src/Zle/zleparameter.c	Tue Mar  7 13:31:44 2006
+++ zsh-bindkey-crash/Src/Zle/zleparameter.c	Mon May 21 18:52:20 2007
@@ -75,6 +75,8 @@ createspecialhash(char *name, GetNodeFun
 static char *
 widgetstr(Widget w)
 {
+    if (!w)
+	return dupstring("undefined");
     if (w->flags & WIDGET_INT)
 	return dupstring("builtin");
     if (w->flags & WIDGET_NCOMP) {
@@ -127,6 +129,8 @@ scanpmwidgets(UNUSED(HashTable ht), Scan
 
     for (i = 0; i < thingytab->hsize; i++)
 	for (hn = thingytab->nodes[i]; hn; hn = hn->next) {
+	    if (!((Thingy) hn)->widget)
+		continue;
 	    pm.node.nam = hn->nam;
 	    if (func != scancountparams &&
 		((flags & (SCANPM_WANTVALS|SCANPM_MATCHVAL)) ||

Re: bindkey <whatever> history-beginning-search-backwards; echo $widgts = crash

[Maddi Kopfermann]

Am Montag, dem 21. Mai 2007 um 18:46 Uhr, Phil Pennock:
> 
> history-beginning-search-backwards is not a standard widget; aside from
> this bug, you need to find which widget you really want.

zsh -fc "bindkey '^o' history-beginning-backward && echo $widgets"

crashes the shell

zsh -fc "bindkey '^o' history-beginning-backwards && echo $widgets"

crashes the shell

zsh -fc "bindkey '^o' history-beginning-forward && echo $widgets"

crashes the shell

zsh -fc "bindkey '^o' history-beginning-<TAB> && echo $widgets"
crashes the shell

the attempt to let completion work crashes the shell.
> This is a bug when there is no widget with the supplied name;

Sadly not only in that case!

                Matthias

Re: bindkey <whatever> history-beginning-search-backwards; echo $widgts = crash

[Bart Schaefer]

On May 22,  5:32am, Maddi Kopfermann wrote:
} 
} > This is a bug when there is no widget with the supplied name;
} 
} Sadly not only in that case!

Why do you think so?  In every example you gave, you first bound a key
to a widget that does not exist, and then tried to echo $widgets.

} zsh -fc "bindkey '^o' history-beginning-<TAB> && echo $widgets"
} crashes the shell
} 
} the attempt to let completion work crashes the shell.

I don't understand what that example is supposed to be showing.  What
do you mean by "let completion work"?  Completion only happens in the
line editor in an interactive shell, you can't pass a literal tab to
zsh -fc and expect anything to happen.  And even if you mean that you
did type a tab in ZLE, the completion you show would be ambiguous --
ordinarily it would take more than one tab at that position to complete
a valid widget name.

Re: bindkey <whatever> history-beginning-search-backwards; echo $widgts = crash

[Phil Pennock]

On 2007-05-22 at 05:32 +0200, Maddi Kopfermann wrote:
> Am Montag, dem 21. Mai 2007 um 18:46 Uhr, Phil Pennock:
> > 
> > history-beginning-search-backwards is not a standard widget; aside from
> > this bug, you need to find which widget you really want.
> 
> zsh -fc "bindkey '^o' history-beginning-backward && echo $widgets"
> 
> crashes the shell
> 
> zsh -fc "bindkey '^o' history-beginning-backwards && echo $widgets"
> 
> crashes the shell
> 
> zsh -fc "bindkey '^o' history-beginning-forward && echo $widgets"
> 
> crashes the shell
> 
> zsh -fc "bindkey '^o' history-beginning-<TAB> && echo $widgets"
> crashes the shell
> 
> the attempt to let completion work crashes the shell.
> > This is a bug when there is no widget with the supplied name;
> 
> Sadly not only in that case!

But, uhm, those aren't widgets; see zshzle(1) for details.
history-beginning-<TAB> would take you as far as
history-beginning-search- but that's not a complete widget, there are
four different widgets with that prefix.  Well, okay, you might be set
up to tab-complete further.  But not in zsh -fc "cmd..." -- if someone
has completion set up to correctly work recursively there, I'd like to
know the settings.

history-search-forward ?  history-beginning-search-forward ?  And also
"-backward".

Meanwhile,
% zsh -fc "cmdname"
will execute cmdname in a non-interactive shell and without any startup
files you might have; but the variables inside that need escaping so
that they'll be expanded by the non-interactive shell.  I think you
want:

% zsh -fc 'bindkey "^o" history-beginning-search-forward; echo $widgets'

And FWIW the supplied patch does prevent this crashing when given a bad
name.

Re: bindkey <whatever> history-beginning-search-backwards; echo $widgts = crash

[Maddi Kopfermann]

On Mon, May 21, 2007 at 10:37:29PM -0700, Bart Schaefer:
> } Sadly not only in that case!
> 
> Why do you think so?  In every example you gave, you first bound a key
> to a widget that does not exist, and then tried to echo $widgets.
> 
> } zsh -fc "bindkey '^o' history-beginning-<TAB> && echo $widgets"
> } crashes the shell
> } 
> } the attempt to let completion work crashes the shell.
> 
> I don't understand what that example is supposed to be showing.  What
> do you mean by "let completion work"?  Completion only happens in the
> line editor in an interactive shell, you can't pass a literal tab to
> zsh -fc and expect anything to happen.  And even if you mean that you
> did type a tab in ZLE, the completion you show would be ambiguous --
> ordinarily it would take more than one tab at that position to complete
> a valid widget name.

I see my mistake. Whatever I did was with an already
"infected" zsh so that _every_ "echo $widgets" does crash it,
no matter what i write before it.
In a zsh without any configuration  (zsh -f) those described cases
_don't_ crash the shell.

                Matthias

Re: bindkey <whatever> history-beginning-search-backwards; echo $widgts = crash

[Peter Stephenson]

On Mon, 21 May 2007 18:59:23 -0700
Phil Pennock <zsh-workers+phil.pennock@spodhuis.org> wrote:
> On 2007-05-21 at 18:46 -0700, Phil Pennock wrote:
> > This is a bug when there is no widget with the supplied name; the
> > value for the type can't be calculated.  The code which loops over
> > the widgets doesn't notice that the widget doesn't really exist and
> > the code which produces a stringification doesn't handle it.
> 
> Is it better for the $widgets associative array to pretend that such a
> key doesn't exist, or to acknowledge that it does exist with undefined
> value?

I think the latter.  If the user is convinced the widget should exist
and has tried to bind something to it the shell should show as much.
The juice stains the lips, the stain acts as a warning (as it were).
(No, that doesn't really make sense.)

I've committed that patch.  Thanks.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview

Re: bindkey <whatever> history-beginning-search-backwards; echo $widgts = crash

[Maddi Kopfermann]

On Mon, May 21, 2007 at 10:55:37PM -0700, Phil Pennock:
> 
> % zsh -fc 'bindkey "^o" history-beginning-search-forward; echo $widgets'

right, this does not crash the shell here, thanks!
Thanks for the solution!
I should have waited 'til being awake before trying it out
and saying: "It crashes the shell".
400 lines of zsh bindings need a little more checkup on my
part :)

> And FWIW the supplied patch does prevent this crashing when given a bad
> name.

Makes sense,

                Matthias

bindkey <whatever> history-beginning-search-backwards; echo $widgts = crash

[Maddi Kopfermann]

Hi Zsh Comrades,

Yesterday i found what it seems to be a very old bug.

bindkey <whatever> history-beginning-search-backwards &&
echo $widgets crashes zsh, it does with zsh -f.
On #zsh Frank Terbeck had it crash even with 3.1.7. All
versions that have history-beginning-search-backwards did
crash, it seems.

gdb zsh core has:

        Program terminated with signal 11, Segmentation
        fault.
        #0  widgetstr (w=0x0) at
        ../../../Src/Zle/zleparameter.c:78
        78      ../../../Src/Zle/zleparameter.c: No such
        file or directory.
                in ../../../Src/Zle/zleparameter.c


                Greetings,
                        Matthias