Wrong build on SunOS 5.8 or bug in zsh?

Wrong build on SunOS 5.8 or bug in zsh?

[Andreas Pistoor]

Hello,
we switched from ksh to zsh, when our main application was ported from
AIX on ppc to Linux/Gnu on ia32. Later we introduced zsh-only-code into
our scripts and ported our application for a new customer to SunOS 5.8
on sparc.
On Linux, AIX and our develop-SunOS the zsh works fine, but on our
SunOS-production-machines some long running scripts, which starts many
subjobs and waits for them, get from time to time a signal SIGBUS (or
maybe SIGILL or SIGSEGV, I am not sure about older events). Sometimes
this signal was resent while the zsh was in the code to buffer a
previous signal in its internal list, resulting in overflowing this list
and locking the shell. At other times, the signal was traped and resent
while trying to exit the shell in that trap, also locking the shell. The
last time, now without the traps on that signals, a subshell called by
$( ... ) exited.
In production, at most nights 5 such longrunning scripts are running and
around once in a month such a signal is recieved.
As we can not reproduce the problem on our development machine, I ask,
whether you have some knowledge about problems of the zsh on SunOS and
Sparc. We are now using zsh-4.2.5 which were compiled with gcc-3.3.2 and
configure-options --enable-libs=/usr/local/lib/libiconv.so
--prefix=$PWD//usr.
To check for heap-problems, I tried bcheck (a script on top of RTC, a
runtimechecker of the heap, of the Sun-compiler and -debugger), which
told, it would disable the errorchecking, as there was an internal RTC
error in memmap.c and some lock was broken in malloc.c, and own
testroutines as malloc, realloc, calloc and free, which did not found
problems.

Thank you for your time
Andreas Pistoor
Softwaredeveloper in Germany

Re: Wrong build on SunOS 5.8 or bug in zsh?

[Peter Stephenson]

Andreas Pistoor wrote:
> On Linux, AIX and our develop-SunOS the zsh works fine, but on our
> SunOS-production-machines some long running scripts, which starts many
> subjobs and waits for them, get from time to time a signal SIGBUS (or
> maybe SIGILL or SIGSEGV, I am not sure about older events). Sometimes
> this signal was resent while the zsh was in the code to buffer a
> previous signal in its internal list, resulting in overflowing this list
> and locking the shell. At other times, the signal was traped and resent
> while trying to exit the shell in that trap, also locking the shell. The
> last time, now without the traps on that signals, a subshell called by
> $( ... ) exited.

It would be useful to see a gdb backtrace of the state the shell is in
if it locks, or of a core dump, if you can get one.

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


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************