Re: Bug#101523: zsh segmentation fault

Re: Bug#101523: zsh segmentation fault

[Clint Adams]

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

On Tue, Jun 19, 2001 at 10:56:33PM +0200, Michal Politowski wrote:

> zsh segfaults when trying to source /usr/share/shoop/shoop.sh from the shoop package.
> Unfortunately this file is rather complicated and I can't provide a smaller
> example.

I can reproduce this with zsh --no-equals -fx shoop.sh

shoop.sh is attached

[-- Attachment #2: shoop.sh --]
[-- Type: text/x-sh, Size: 3320 bytes --]

#!/bin/sh -e
# This script has been preprocessed prior to installation
# It has had comments, blank lines, and leading spaces
# removed, and \-style lines combined.  This was done so
# that it could run quicker under some shells.
_shoop () {
local TRUEOBJ=$1 TRYOBJ=$2 METH=$3 TRUEMETH=$1_$3 TRYMETH=$2_$3 LASTMETH=$METH
shift 3
case "$1" in
=|=q|=p|.=|.=q|.=p|.=qp|:|:p)
local varmeth=$1 append="" quiet="" private=""; shift
if [ "${varmeth%p}" != $varmeth ]; then private=1; varmeth=${varmeth%p}; fi
if [ "$_shoop_introspect" ] &&
eval [ -z \"\$_shooptype_$TRYMETH\$private\" ]; then
eval "_shoopdefines_$TRUEOBJ=\"\$_shoopdefines_$TRUEOBJ $METH\""
fi
if [ -z "$_shoopnocache_" ]; then
eval $_shoopcacheclear_
fi
if [ "${varmeth#.}" != $varmeth ]; then append=1 varmeth=${varmeth#.}; fi
if [ "${varmeth%q}" != $varmeth ]; then quiet=1 varmeth=${varmeth%q}; fi
if [ "$varmeth" = = ]; then
if [ "$append" ];then set -- "$(eval eval "\$_shoop_$TRUEMETH") $@"; fi
if [ ! "$quiet" ]; then echo -n $@; fi
eval "_shoop_$TRUEMETH='echo -n $@'
_shooptype_$TRUEMETH=variable"
else
if [ "$quiet" ]; then echo "Invalid modifier(q) on assignment!($TRUEOBJ.$METH)" >&2; fi
if [ "$append" ];then
eval eval "_shoop_$TRUEMETH=\'\$_shoop_$TRUEMETH;\$@\'
_shooptype_$TRUEMETH=method"
else
eval "_shoop_$TRUEMETH='$@'
_shooptype_$TRUEMETH=method"
fi
fi
return
;;esac
if eval [ \"\$_shooptype_$TRYMETH\" ]; then
local THIS=$TRUEOBJ
eval eval "\$_shoop_$TRYMETH"
return
else
eval local P PARENTS=\"$(eval eval "\$_shoop_${TRYOBJ}_parent")\"			THIS=$TRUEOBJ GETMETH="" NEWPARENTS=""
if [ -z "$_shoopnocache_" ]; then
eval local CACHE=\"\$_shoopcache_link_$TRUEMETH\"
if [ "$CACHE" ]; then
eval eval \$$CACHE
return
fi
fi
for P in $PARENTS; do
eval GETMETH=\"\$_shoop_${P}_$METH\"
if [ "$GETMETH" ]; then
eval "$GETMETH"
return
fi
NEWPARENTS="$NEWPARENTS $(eval eval "\$_shoop_${P}_parent")"
done
local orgargs="$@"
set -- $NEWPARENTS
while [ $# -gt 0 ];do
P=$1
eval GETMETH="\$_shoop_${P}_$METH"
if [ "$GETMETH" ]; then
set -- $orgargs
if [ -z "$_shoopnocache_" ]; then
eval _shoopcache_link_${THIS}_$METH=_shoop_${P}_$METH					     _shoopcache_=\"\$_shoopcache_						  _shoopcache_method_$METH _shoopcache_link_${THIS}_$METH \"					     _shoopcache_method_$METH=\"\$_shoopcache_method_$METH						  _shoopcache_link_${THIS}_$METH\"					     _shoopcache_linkmethod_${P}_$METH=\"\$_shoopcache_linkmethod_${P}_$METH						  _shoopcache_link_${THIS}_$METH\"
fi
eval "$GETMETH"
return
fi
shift
set -- $(eval eval "\$_shoop_${P}_parent") "$@"
done
echo "\"$METH\" is undefined for $TRYOBJ." >&2
return 1
fi
}
IFS=" " _shoopcacheclear_="
if eval [ \\\"\\\$_shoopcache_method_\$METH\\\" ]; then
if eval [ -z \\\"\\\$_shoopcache_linkmethod_\$TRUEMETH\\\" ]; then
eval unset _shoopcache_method_\$METH				 \\\$_shoopcache_method_\$METH				   _shoopcache_linkmethod_\$TRUEMETH				 \\\$_shoopcache_linkmethod_\$TRUEMETH
fi
fi
"
_shoop_introspect=1
IFS=" " _shoop OBJECT OBJECT new :p '
local OBJNAME=$1
eval "$OBJNAME () { shift; _shoop $OBJNAME $OBJNAME \"\$@\"; };"
if [ $THIS != $OBJNAME ]; then
_shoop $OBJNAME $OBJNAME parent = $THIS >/dev/null
fi
eval unset _shoopcache_ \$_shoopcache_ || true
'
_shoop OBJECT OBJECT new OBJECT
OBJECT . parent = ""
OBJECT . super :p '_shoop $THIS $($THIS . parent) "$LASTMETH" "$@"; return'
unset _shoop_introspect

Re: Bug#101523: zsh segmentation fault

[Bart Schaefer]

On Jun 19,  6:33pm, Clint Adams wrote:
}
} I can reproduce this with zsh --no-equals -fx shoop.sh

It's happening when the `=' parameter is (not) restored upon exit from the
function.  I'm not sure that's really the root cause, though.  Trace below.

I will point out that there's a rather nasty bug in shoop.sh on line 61:

    local orgargs="$@"

This will almost certainly not do what is wanted; it'll set orgargs to be
$1 and will make local variables whose names are the rest of the arguments.
Then later,

    set -- $orgargs

will also not produce the desired effect.

------------

BUG: in restoring special parameters
zsh: segmentation fault (core dumped)

zagzig<11> gdb Src/zsh core
GNU gdb 4.17.0.4 with Linux/x86 hardware watchpoint and FPU support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `Src/zsh -o noequals -fx /home/schaefer/Mail/detach.dir/shoop.sh'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /usr/lib/libncurses.so.4...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libnss_files.so.1...done.
#0  0x805f3c2 in restore_params (restorelist=0x40112580, removelist=0x40112588)
    at ../../zsh-4.0/Src/exec.c:2439
2439			tpm->flags = pm->flags;
(gdb) where
#0  0x805f3c2 in restore_params (restorelist=0x40112580, removelist=0x40112588)
    at ../../zsh-4.0/Src/exec.c:2439
#1  0x805eecc in execcmd (state=0xbffffaa8, input=0, output=0, how=18, last1=2)
    at ../../zsh-4.0/Src/exec.c:2315
#2  0x805bacb in execpline2 (state=0xbffffaa8, pcode=5699, how=18, input=0, 
    output=0, last1=0) at ../../zsh-4.0/Src/exec.c:1192
#3  0x805b043 in execpline (state=0xbffffaa8, slcode=11266, how=18, last1=0)
    at ../../zsh-4.0/Src/exec.c:982
#4  0x805a9dd in execlist (state=0xbffffaa8, dont_change_job=0, exiting=0)
    at ../../zsh-4.0/Src/exec.c:826
#5  0x805a6f7 in execode (p=0x401122c8, dont_change_job=0, exiting=0)
    at ../../zsh-4.0/Src/exec.c:729
#6  0x806fcd5 in loop (toplevel=1, justonce=0) at ../../zsh-4.0/Src/init.c:160
#7  0x80724b4 in zsh_main (argc=5, argv=0xbffffb38)
    at ../../zsh-4.0/Src/init.c:1209
#8  0x804a8b4 in main (argc=5, argv=0xbffffb38) at ../../zsh-4.0/Src/main.c:37
(gdb) p pm
$1 = (struct param *) 0x40112590
(gdb) p *pm
$2 = {next = 0x40112568, nam = 0x8124bbc "=", flags = 786432, u = {
    data = 0x8137640, arr = 0x8137640, str = 0x8137640 " ", 
    val = 7309465757271946816, dval = 4.2633628668410461e+180, 
    hash = 0x8137640}, sets = {cfn = 0x998b646e, ifn = 0x998b646e, 
    ffn = 0x998b646e, afn = 0x998b646e, hfn = 0x998b646e}, gets = {cfn = 0x99, 
    ifn = 0x99, ffn = 0x99, afn = 0x99, hfn = 0x99}, unsetfn = 0, ct = 0, 
  env = 0x0, ename = 0x0, old = 0x0, level = 1074866392}
(gdb) p tpm
$3 = (struct param *) 0x0
(gdb) l
2434			Param tpm = (Param) paramtab->getnode(paramtab, pm->nam);
2435	
2436			DPUTS(!tpm || PM_TYPE(pm->flags) != PM_TYPE(tpm->flags) ||
2437			      !(pm->flags & PM_SPECIAL),
2438			      "BUG: in restoring special parameters");
2439			tpm->flags = pm->flags;
2440			switch (PM_TYPE(pm->flags)) {
2441			case PM_SCALAR:
2442			    tpm->sets.cfn(tpm, pm->u.str);
2443			    break;
(gdb) p pm->nam
$4 = 0x8124bbc "="

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Bug#101523: zsh segmentation fault

[Bart Schaefer]

On Jun 19,  6:33pm, Clint Adams wrote:
} 
} On Tue, Jun 19, 2001 at 10:56:33PM +0200, Michal Politowski wrote:
} 
} > zsh segfaults when trying to source /usr/share/shoop/shoop.sh

Incidentally, it executes without crashing if I `emulate sh' first.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

RE: Bug#101523: zsh segmentation fault

[Andrej Borsenkow]

>
> I will point out that there's a rather nasty bug in shoop.sh on line 61:
>
>     local orgargs="$@"
>
> This will almost certainly not do what is wanted; it'll set orgargs to be
> $1 and will make local variables whose names are the rest of the
> arguments.
> Then later,
>
>     set -- $orgargs
>
> will also not produce the desired effect.
>

This is related to export foo=$(cmd) problem we have discussed. Obviously,
other shells treat {export|local|typeset} foo=bar w.r.t. word splitting
exactly the same as foo=bar, i.e. they do not split in assignments here.

Did not we have some patch for it, at least in HEAD? Looks, like it should
be in 4.0.

Have

RE: Bug#101523: zsh segmentation fault

[Andrej Borsenkow]

> >
> > I will point out that there's a rather nasty bug in shoop.sh on line 61:
> >
> >     local orgargs="$@"
> >
> > This will almost certainly not do what is wanted; it'll set
> orgargs to be
> > $1 and will make local variables whose names are the rest of the
> > arguments.
> > Then later,
> >
> >     set -- $orgargs
> >
> > will also not produce the desired effect.
> >
>
> This is related to export foo=$(cmd) problem we have discussed. Obviously,
> other shells treat {export|local|typeset} foo=bar w.r.t. word splitting
> exactly the same as foo=bar, i.e. they do not split in assignments here.
>
> Did not we have some patch for it, at least in HEAD? Looks, like it should
> be in 4.0.


14858

-andrej

Re: Bug#101523: zsh segmentation fault

[Peter Stephenson]

"Bart Schaefer" wrote:
> It's happening when the `=' parameter is (not) restored upon exit from the
> function.  I'm not sure that's really the root cause, though.

No, I think it's when it (or something completely different --- there's no
`=' special parameter) is being saved.  The following looks a safe fix.
Unless anyone knows any better, this will go on both branches.  (Saved
parameters go on the heap since the list they're saved on is removed when
the scope exits.)

Index: Src/exec.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.28
diff -u -r1.28 exec.c
--- Src/exec.c	2001/05/28 09:00:22	1.28
+++ Src/exec.c	2001/06/20 09:58:32
@@ -2395,7 +2395,7 @@
 	    } else if (!(pm->flags & PM_READONLY) &&
 		       (unset(RESTRICTED) || !(pm->flags & PM_RESTRICTED))) {
 		Param tpm = (Param) zhalloc(sizeof *tpm);
-		tpm->nam = s;
+		tpm->nam = dupstring(s);
 		copyparam(tpm, pm, 1);
 		pm = tpm;
 	    }

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Bug#101523: zsh segmentation fault

[Peter Stephenson]

Peter Stephenson wrote:
> -		tpm->nam = s;
> +		tpm->nam = dupstring(s);
>  		copyparam(tpm, pm, 1);

That could simply have been pm->nam on the right hand side, saving the
string duplication, but I don't have the energy to change it, test it, and
check it in again.  If anyone else wants to...

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Bug#101523: zsh segmentation fault

[Bart Schaefer]

On Jun 20, 10:51am, Andrej Borsenkow wrote:
} Subject: RE: Bug#101523: zsh segmentation fault
}
} >     local orgargs="$@"
} >
} > This will almost certainly not do what is wanted; it'll set orgargs to be
} > $1 and will make local variables whose names are the rest of the
} > arguments.
} 
} This is related to export foo=$(cmd) problem we have discussed. Obviously,
} other shells treat {export|local|typeset} foo=bar w.r.t. word splitting
} exactly the same as foo=bar, i.e. they do not split in assignments here.

I don't doubt it, but as you pointed out yourself the POSIX-defined
behavior is to split the arguments of those commands.  If the authors
of shoop, whoever they are, want it to be portable, they should be
avoiding this conflict.  It's easy enough to use

	local orgargs="$*"

instead.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

KSH_TYPESET and 4.0.2

[Bart Schaefer]

On Jun 20, 11:59am, Andrej Borsenkow wrote:
} Subject: RE: Bug#101523: zsh segmentation fault
}
} > >     local orgargs="$@"
} >
} > This is related to export foo=$(cmd) problem we have discussed.
} >
} > Did not we have some patch for it, at least in HEAD? Looks, like it should
} > be in 4.0.
} 
} 14858

Can we get a few more votes on whether KSH_TYPESET should go in 4.0.2?

I note that we still haven't resolved the bash-compatibility issue.  Other
than that, though, I see no reason not to include it.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: KSH_TYPESET and 4.0.2

[Peter Stephenson]

"Bart Schaefer" wrote:
> Can we get a few more votes on whether KSH_TYPESET should go in 4.0.2?
> 
> I note that we still haven't resolved the bash-compatibility issue.  Other
> than that, though, I see no reason not to include it.

It's not exactly a bug fix, but after fixing the setting of individual
positional params it doesn't seem to be problematic.  If it looks like
people are running across this difference I don't mind it going in.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************