seg fault on $(dgqhghdqwdhqwjq) : beta19

seg fault on $(dgqhghdqwdhqwjq) : beta19

[Anthony Heading]

Rather a large core file, but it takes no time to dump.  So maybe
it's not real. A peculiarity of SunOS 4.1.3?

Anthony

res1% $(wekdwqw)
zsh: command not found: wekdwqw
zsh: 21441 segmentation fault  $(wekdwqw)
res1% ls -l core 
-rw-r--r--  1 aheading 2139365808 May 24 22:04 core
res1% 

Re: seg fault on $(dgqhghdqwdhqwjq) : beta19

[Hrvoje Niksic]

In your mail, you said:
> Rather a large core file, but it takes no time to dump.  So maybe
> it's not real. A peculiarity of SunOS 4.1.3?

I believe the size of the core file is a SunOS peculiarity (and I don't
think it's real either -- I used to ged "400M" core files without a
slightest change in df output).

As per the bug itself, I could not reproduce it on SunOS, but running a
non-existent command in backquotes returns me to the current directory (I
have autocd setopt-ed). I think this also counts as a bug. Oh, yes, I did
reproduce it on Linux, like:

Script started, file is typescript
gnjilux% setopt autocd
gnjilux% echo $ZSH_VERSION
2.6-beta19
gnjilux% pwd
/home/hniksic/work/zsh-2.6-beta19
gnjilux% $(obviously_not_in_path)
zsh: command not found: obviously_not_in_path
zsh: segmentation fault  $(obviously_not_in_path)
gnjilux% 

It is kernel 1.99.7.

-- 
hniksic@srce.hr              |  Student of electrical engineering
hniksic@fly.cc.fer.hr        |  University of Zagreb, Croatia
------------------------------------------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

Re: seg fault on $(dgqhghdqwdhqwjq) : beta19

[Zoltan Hidvegi]

> Rather a large core file, but it takes no time to dump.  So maybe
> it's not real. A peculiarity of SunOS 4.1.3?
> 
> Anthony
> 
> res1% $(wekdwqw)
> zsh: command not found: wekdwqw
> zsh: 21441 segmentation fault  $(wekdwqw)

It always happens when prefork() in execcmd() removes all arguments.
Eg. $foo triggers the bug if foo is not set.  Richard did several changes
related to this and I think this bug appeared with these changes.  Richard,
could you check it?

Zoltan

Re: seg fault on $(dgqhghdqwdhqwjq) : beta19

[Thorsten Meinecke]

> > res1% $(wekdwqw)
> > zsh: command not found: wekdwqw
> > zsh: 21441 segmentation fault  $(wekdwqw)
> 
> It always happens when prefork() in execcmd() removes all arguments.
> Eg. $foo triggers the bug if foo is not set.

zsh's child dies in execute(), exec.c:243, when it tries to access
the empty argument list.  But there's more to this than only that:

The exit code doesn't make sense when command substitution happens
in command position, eg.

  % ./zsh -fc '$(true); echo $?'
  139
  % ./zsh -fc '$(false); echo $?'
  139

Both bash and pd-ksh say `0' and '1' here, respectively.  They both
give an exit code of `127' if the command isn't found.  What's the
Right Thing?

Regards,
--Thorsten

Re: seg fault on $(dgqhghdqwdhqwjq) : beta19

[Zefram]

>  % ./zsh -fc '$(true); echo $?'
>  139
>  % ./zsh -fc '$(false); echo $?'
>  139

139 <=> death with signal 11 <=> SIGSEGV on most systems.

-zefram

Re: seg fault on $(dgqhghdqwdhqwjq) : beta19

[Thorsten Meinecke]

> >  % ./zsh -fc '$(true); echo $?'
> >  139
> >  % ./zsh -fc '$(false); echo $?'
> >  139
> 
> 139 <=> death with signal 11 <=> SIGSEGV on most systems.
> 
> -zefram

Oops.  Yes, core dumps nicely here.

Let me reword my question.  Since this doesn't work with releases
prior to beta16 either ("no command"):  Is it supposed to work?

Regards,
--Thorsten

PS.  On a totally unrelated note:  After `bindkey <any-key> prefix',
beta19 signals SEGV, when the new prefix is entered the first time.

Re: seg fault on $(dgqhghdqwdhqwjq) : beta19

[Zefram]

>PS.  On a totally unrelated note:  After `bindkey <any-key> prefix',
>beta19 signals SEGV, when the new prefix is entered the first time.

I'm aware of problems in this area; it's on my to-do list.  You
shouldn't actually be able to bind to prefix directly anyway.

-zefram

Re: seg fault on $(dgqhghdqwdhqwjq) : beta19

[Richard Coleman]

> > res1% $(wekdwqw)
> > zsh: command not found: wekdwqw
> > zsh: 21441 segmentation fault  $(wekdwqw)
> 
> It always happens when prefork() in execcmd() removes all arguments.
> Eg. $foo triggers the bug if foo is not set.  Richard did several changes
> related to this and I think this bug appeared with these changes.  Richard,
> could you check it?
> 
> Zoltan
> 

I recently removed the piece of code

    if (empty(args)) {
        zerr("no command", NULL, 0);
        _exit(1);
    }

from the beginning of execute() in exec.c since `args' should not
be empty at this point.  It appears this uncovered a bug higher up
the execution pipeline (this was my very intention, of course).
Rather than putting this piece of code back, we should probably fix
this in execcmd() or prefork().

There were a couple of other places I removed such checks.  I hate
these types of checks since they cover up bugs rather than fix them.
In my opinion, the check in dotrap() for errflag (which was recently
added) is in this category.  If errflag=1, then you shouldn't have
called dotrap in the first place.

rc

Re: seg fault on $(dgqhghdqwdhqwjq) : beta19

[Peter Stephenson]

hzoli@cs.elte.hu wrote:
> > res1% $(wekdwqw)
> > zsh: command not found: wekdwqw
> > zsh: 21441 segmentation fault  $(wekdwqw)
> 
> It always happens when prefork() in execcmd() removes all arguments.

It's not quite that simple: prefork turns the first argument into an
empty string, so the argument list isn't quite null and negotiates all
the tests for nonempty(args).  However, fixcline() then comes along
and unhooks the empty argument, leaving an empty list.  This is when
the trouble starts.  Maybe the substitution code needs to be smarter
and unhook its own null arguments, then we can handle empty lines
more consistently in execcmd().  I suppose this goes in prefork().

By the way, it's handled OK with double quotes present:

% zsh -fc '"$(doallmyworkforme)"'
zsh: command not found: doallmyworkforme
zsh: permission denied: 

since there's no command matching the null string.  If that's
acceptable when the quotes are missing (behaviour of other shells
suggests it isn't), a simpler solution is to adapt fixcline() to leave
an empty string if its the only thing left on the line.

Could we simply call fixcline() after or even in prefork(), leaving the
way open for sensible tests in execcmd()?

-- 
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.