Another zsh 3.1 bug -- localization?

Another zsh 3.1 bug -- localization?

[SL Baur]

I've tested this now on zsh 3.1.2 and zsh 3.1.3 Linux libc5 and GNU
libc.  It does not occur in zsh 3.0.4 or zsh 3.0.5.  It reproduces
reliably for me in a new zsh-3.1.3 (without the `unset CDPATH'
bugfix).  The machine I'm running on is localizable to the extent that
`LANG=ja' is able to programs that need Japanese input and display
Japanese output.

$ Src/zsh
$ LC_ALL=C; export LC_ALL; LANC=C; export LANG; date
zsh: 30841 segmentation fault (core dumped)  Src/zsh

[The misspelling of LANC=C is deliberate and duplicates the typo in
the GNU Awk 3.0.3 package].

The stack backtrace is cryptic:

$ LC_ALL=C; export LC_ALL; LANC=C; export LANG
# the previous step requires me to be running zsh-3.0
$ gdb src/Zsh 
(gdb) run -c date
Starting program: /usr/local/src/bin/zsh-3.1.3/Src/zsh -c date
Program received signal SIGTRAP, Trace/breakpoint trap.
0x400009d0 in lastmailcheck ()
(gdb) where
#0  0x400009d0 in lastmailcheck ()
Cannot access memory at address 0x80ad2f0.

Re: Another zsh 3.1 bug -- localization?

[Zoltan Hidvegi]

SL Baur wrote:
> I've tested this now on zsh 3.1.2 and zsh 3.1.3 Linux libc5 and GNU
> libc.  It does not occur in zsh 3.0.4 or zsh 3.0.5.  It reproduces
> reliably for me in a new zsh-3.1.3 (without the `unset CDPATH'
> bugfix).  The machine I'm running on is localizable to the extent that
> `LANG=ja' is able to programs that need Japanese input and display
> Japanese output.
> 
> $ Src/zsh
> $ LC_ALL=C; export LC_ALL; LANC=C; export LANG; date
> zsh: 30841 segmentation fault (core dumped)  Src/zsh

A simple export LANG is enough for the coredump.  Any unset special
parameter will do, but LANG is unset by default.  The patch below fixes
this, but it introduces a slightly inconsistent behavior.  export LANG
will not set LANG, but if it is set later, it will be exported.  This is
similar to ksh, but inconsistent with zsh, which creates the parameter
with empty value when export used on a previously unset parameter.

An alternative fix would change the big if statement near line 1557,
which is now

if ((pm = (Param)paramtab->getnode(paramtab, asg->name)) &&
    (((pm->flags & PM_SPECIAL) && pm->level == locallevel) ||
     (!(pm->flags & PM_UNSET) &&
      ((locallevel == pm->level) || func == BIN_EXPORT) &&
      !(bit = ((off & pm->flags) | (on & ~pm->flags)) & PM_INTEGER))))

If the condition is changed to always be false when pm->flags & PM_UNSET
and createparam is changed to reset the unset flag and return the
parameter, it would probably work, and that's how it works in 3.0.5.
This has been changed since 3.0.5 by patch 3048 from Zefram which allowd
local parameters to hide special parameters.  I do not completely
understand this, but someone hopefully knows better.

Note that in the patch below addenv is not called when asg->value is
non-null (i.e. when a value is given in the typeset/export statement),
because in this case the later setsparm call does the addenv.

Zoltan


*** Src/builtin.c.orig	Fri May  8 01:24:52 1998
--- Src/builtin.c	Mon May 18 01:37:59 1998
*************** bin_typeset(char *name, char **argv, cha
*** 1585,1592 ****
  		pm->ct = auxlen;
  	    if (PM_TYPE(pm->flags) != PM_ARRAY) {
  		if (pm->flags & PM_EXPORTED) {
! 		    if (!pm->env)
! 			pm->env = addenv(asg->name, (asg->value) ? asg->value : getsparam(asg->name));
  		} else if (pm->env) {
  		    delenv(pm->env);
  		    zsfree(pm->env);
--- 1585,1592 ----
  		pm->ct = auxlen;
  	    if (PM_TYPE(pm->flags) != PM_ARRAY) {
  		if (pm->flags & PM_EXPORTED) {
! 		    if (!(pm->flags & PM_UNSET) && !pm->env && !asg->value)
! 			pm->env = addenv(asg->name, getsparam(asg->name));
  		} else if (pm->env) {
  		    delenv(pm->env);
  		    zsfree(pm->env);

Re: Another zsh 3.1 bug -- localization?

[SL Baur]

Zoltan Hidvegi <hzoli@cs.elte.hu> writes:

> A simple export LANG is enough for the coredump.

Right, did my followup message get through?

> Any unset special parameter will do, but LANG is unset by default.
> The patch below fixes this, but it introduces a slightly inconsistent
> behavior.

Tested and verified.  Thanks.

I've also found some zle anomalies in 3.1.2.  I'll start checking
3.1.3 for them.