Signal-handling problem

Signal-handling problem

[DEW16]

Hello, all.  Okay, so I *LOVE*  zsh, but I  have a small problem.  For some
reason, my build doesn't know how to handle signals.  For example, if I type:

dave(4):[~]% echo $ZSH_VERSION
3.0.5
dave(4):[~]% kill -l
ZERR

it only shows "ZERR".  If I do the same thing in bash, I get:

dave(173):[~]% kill -l
 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL
 5) SIGTRAP      6) SIGABRT      7) SIGEMT       8) SIGFPE
 9) SIGKILL     10) SIGBUS      11) SIGSEGV     12) SIGSYS
13) SIGPIPE     14) SIGALRM     15) SIGTERM     16) SIGUSR1
17) SIGUSR2     18) SIGCHLD     19) SIGPWR      20) SIGWINCH
21) SIGURG      22) SIGIO       23) SIGSTOP     24) SIGTSTP
25) SIGCONT     26) SIGTTIN     27) SIGTTOU     28) SIGVTALRM
29) SIGPROF     30) SIGXCPU     31) SIGXFSZ

All signals seem to kill my zsh and dump a core.  Here's some gdb output from
one of them (caused by trying to suspend a job with CTRL-Z):

dave(3):[~]% gdb zsh core
GNU gdb 4.17
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 "mips-sgi-irix6.4"...
Core was generated by `zsh'.
Program terminated with signal 10, Bus error.
Reading symbols from /usr/lib32/libcurses.so...done.
Reading symbols from /usr/lib32/libc.so.1...done.
#0  0x10057390 in dupstruct ()
(gdb) backtrace
#0  0x10057390 in dupstruct ()
#1  0x1004be04 in dotrapargs ()
#2  0x1004bf3c in dotrap ()
#3  0x1004b680 in handler ()
#4  <signal handler called>
#5  0xfa3cab8 in ksigprocmask () at crypt.c:105
(gdb)

Any ideas how I can fix this?  (I compiled 'out-of-the-box', with no changes to
the configure script.)  I really hope it's possible, because I *really* like
this shell!  My platform is an SGI Onyx2 running IRIX 6.4...

TIA,

Dave Wolfe
gForce Techologies
c/o DaimlerChrysler

Re: Signal-handling problem

[DEW16]

DEW16@daimlerchrysler.com wrote:
>> Okay, so I *LOVE*  zsh, but I seem to have a small problem.  For some reason,
>> it doesn't know how to handle signals.

Peter Stephenson <pws@ibmth.df.unipi.it> wrote:
>The test for finding the signal names has obviously failed on your OS, so
>the array is far too short and when an unknown signal comes the shell looks
>for something which isn't there <snip!>

Say, thank you and everyone else for the tips.  You were precisely correct. I'm
using zsh
3.0.5, and I discovered that, for some reason, my version of gawk (3.0.3) wasn't
working correctly when invoked to create signals.h.  I was able to sidestep this
by editing the Makefile in the Src directory so that AWK = nawk (instead of
gawk) and recompiling.  The output from 'kill -l' looks reasonable now (i.e.,
it's not empty!) and the signal-handling seems to work just fine...

Thanks again,

-Dave

Re: Signal-handling problem

[Peter Stephenson]

DEW16@daimlerchrysler.com wrote:
> Okay, so I *LOVE*  zsh, but I seem to have a small problem.  For some reason,
>  it
> doesn't know how to handle signals.

The test for finding the signal names has obviously failed on your OS, so
the array is far too short and when an unknown signal comes the shell looks
for something which isn't there.  You didn't say which version of zsh you
have, but this mechanism has changed recently.  The latest attempt is in
http://www.ifh.de/~pws/computing/zsh-3.1.5-pws-11.tar.gz , but there is a
relevant patch which has just appeared in zsh-workers message 5724,
currently available at http://www.zsh.org/mla/workers/1999/msg00768.html
(there's a better way of locating it by number but I couldn't get it to
work).

If that still doesn't work, it will need someone to look at what
Src/signames1.awk and Src/signames2.awk are doing with this compiler and
OS.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Signal-handling problem

[DEW16]

Okay, so I *LOVE*  zsh, but I seem to have a small problem.  For some reason, it
doesn't know how to handle signals.  For example, if I type:

dave(4):[~]% kill -l
ZERR

it only shows "ZERR".  If I do the same thing in bash, I get:

dave(173):[~]% kill -l
 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL
 5) SIGTRAP      6) SIGABRT      7) SIGEMT       8) SIGFPE
 9) SIGKILL     10) SIGBUS      11) SIGSEGV     12) SIGSYS
13) SIGPIPE     14) SIGALRM     15) SIGTERM     16) SIGUSR1
17) SIGUSR2     18) SIGCHLD     19) SIGPWR      20) SIGWINCH
21) SIGURG      22) SIGIO       23) SIGSTOP     24) SIGTSTP
25) SIGCONT     26) SIGTTIN     27) SIGTTOU     28) SIGVTALRM
29) SIGPROF     30) SIGXCPU     31) SIGXFSZ

All signals seem to kill my zsh and dump a core.  Here's some gdb output from
one of them (caused by trying to suspend a job with CTRL-Z):

dave(3):[~]% gdb zsh core
GNU gdb 4.17
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 "mips-sgi-irix6.4"...
Core was generated by `zsh'.
Program terminated with signal 10, Bus error.
Reading symbols from /usr/lib32/libcurses.so...done.
Reading symbols from /usr/lib32/libc.so.1...done.
#0  0x10057390 in dupstruct ()
(gdb) backtrace
#0  0x10057390 in dupstruct ()
#1  0x1004be04 in dotrapargs ()
#2  0x1004bf3c in dotrap ()
#3  0x1004b680 in handler ()
#4  <signal handler called>
#5  0xfa3cab8 in ksigprocmask () at crypt.c:105
(gdb)

Any ideas how I can fix this?  (I compiled 'out-of-the-box', with no changes to
the configure script.)  I really hope it's possible, because I *really* like
this shell!  My platform is an SGI Onyx2 running IRIX 6.4...

TIA,

Dave Wolfe
gForce Techologies
c/o DaimlerChrysler