zsh 3.0.7 coredump

zsh 3.0.7 coredump

[John Harres]

I vaguely remember hearing something about this, but in searching the 
archives I have found nothing.

I seem to be having a problem with zsh handling signals causing 
coredumps.  It seems as if a process being run under zsh gets a signal, it 
triggers a zsh coredump.  I'm using 3.0.7 on Solaris 8 beta.

After forcing a coredump of a running process, zsh coredumps as 
well.  Please let me know if there's anything further I can provide to help 
diagnose this.

mage% dbx /usr/local/bin/zsh core
Reading zsh
core file header read successfully
Reading ld.so.1
Reading libnsl.so.1
Reading libcurses.so.1
Reading libc.so.1
Reading libdl.so.1
Reading libmp.so.2
Reading libc_psr.so.1
Reading en_US.so.2
program terminated by signal SEGV (no mapping at the fault address)
(/opt/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx) where
=>[1] strlen(0x0, 0x8, 0x8c210, 0x7efefeff, 0x81010100, 0x0), at 0xff1b79fc
   [2] printjob(0x94b74, 0x1, 0xff00, 0x0, 0x0, 0x0), at 0x40a98
   [3] update_job(0x94b74, 0x94800, 0xffbeece0, 0x94b74, 0x94b74, 0x1), at 
0x408a0
   [4] handler(0x78, 0x0, 0xffbeedf8, 0xff23a000, 0x0, 0x0), at 0x4f460
   [5] sigacthandler(0x12, 0x0, 0xffbeedf8, 0x0, 0x21838, 0x4f244), at 
0xff21cd58
   ---- called from signal handler with signal 18 (SIGCLD) ------
   [6] _libc_sigsuspend(0x4, 0x0, 0xffbef110, 0x0, 0x21838, 0x4f244), at 
0xff21d010
   [7] signal_suspend(0x12, 0x0, 0x50, 0x0, 0x0, 0x0), at 0x4f244
   [8] waitjob(0x94b74, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x41638
   [9] waitjobs(0x0, 0x95800, 0x90400, 0x1, 0x0, 0x48768), at 0x4174c
   [10] execpline(0x8c000, 0x959f0, 0x8c000, 0x96000, 0x8c000, 0x90400), at 
0x2e614
   [11] execlist(0x9b040, 0x95800, 0x0, 0x4, 0x0, 0x0), at 0x2df3c
   [12] loop(0x1, 0x96000, 0x96000, 0x95400, 0x1, 0x0), at 0x3da4c
   [13] main(0x79400, 0x79400, 0xffbef4d8, 0x94a30, 0x0, 0x0), at 0x3d870
(/opt/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx) quit
mage% echo $ZSH_VERSION
3.0.7

Please respond directly,
John Harres

Re: zsh 3.0.7 coredump

[Bart Schaefer]

On Jan 11, 10:14am, Sven Wischnowsky wrote:
} Subject: Re: zsh 3.0.7 coredump
}
} John Harres wrote:
} 
} > After forcing a coredump of a running process, zsh coredumps as 
} > well.  Please let me know if there's anything further I can provide to help 
} > diagnose this.
} 
} I can't reproduce this with 3.1.6++. An exact recipe and a stack trace 
} of a debugging-compiled shell (so that we can find out which strlen()
} is called with a zero argument) would be helpful.

In particular I'd like to hear what you did to "force a coredump."  It's
possible that you're causing zsh to index into a null part of the sigmsg[]
array when it's printing the reason for the core dump.

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

Re: zsh 3.0.7 coredump

[Sven Wischnowsky]

John Harres wrote:

> I vaguely remember hearing something about this, but in searching the 
> archives I have found nothing.
> 
> I seem to be having a problem with zsh handling signals causing 
> coredumps.  It seems as if a process being run under zsh gets a signal, it 
> triggers a zsh coredump.  I'm using 3.0.7 on Solaris 8 beta.
> 
> After forcing a coredump of a running process, zsh coredumps as 
> well.  Please let me know if there's anything further I can provide to help 
> diagnose this.

I can't reproduce this with 3.1.6++. An exact recipe and a stack trace 
of a debugging-compiled shell (so that we can find out which strlen()
is called with a zero argument) would be helpful.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de