From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25763 invoked from network); 24 Jun 1999 15:26:53 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 24 Jun 1999 15:26:53 -0000 Received: (qmail 22708 invoked by alias); 24 Jun 1999 15:26:29 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6828 Received: (qmail 22701 invoked from network); 24 Jun 1999 15:26:28 -0000 Date: Thu, 24 Jun 1999 17:26:48 +0200 From: Jos Backus To: zsh-workers@sunsite.auc.dk Subject: Re: 3.0.6-pre-5 problem Message-ID: <19990624172648.A8744@hal.mpn.cp.philips.com> Reply-To: Jos Backus References: <19990624170543.A750@hal.mpn.cp.philips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <19990624170543.A750@hal.mpn.cp.philips.com>; from Jos Backus on Thu, Jun 24, 1999 at 05:05:43PM +0200 More info: I just rebuilt zsh with --enable-zsh-debug. Now, when I start an xterm, start mutt (using the function) and press ^Z, both mutt and the xterm disappear, leaving a zsh.core file behind. See stacktrace. Interestingly, this backtrace looks quite different from the first one. hal:~% gdb /bin/zsh zsh.core GNU gdb 4.18 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 "i386-unknown-freebsd"... Core was generated by `zsh'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libtermcap.so.2...done. Reading symbols from /usr/lib/libc.so.3...done. Reading symbols from /usr/libexec/ld-elf.so.1...done. #0 0x805a2ed in execpline (l=0x80c57d8, how=2, last1=0) at exec.c:774 774 for (pn = jobtab[jn->other].procs; pn; pn = pn->next) (gdb) where #0 0x805a2ed in execpline (l=0x80c57d8, how=2, last1=0) at exec.c:774 #1 0x8059db7 in execlist (list=0x80c5850, dont_change_job=0, exiting=0) at exec.c:612 #2 0x806b6ec in loop (toplevel=1, justonce=0) at init.c:143 #3 0x806b47d in main (argc=1, argv=0xbfbfd628) at init.c:75 (gdb) list 769 770 curjob = newjob; 771 DPUTS(!list_pipe_pid, "invalid list_pipe_pid"); 772 addproc(list_pipe_pid, list_pipe_text); 773 774 for (pn = jobtab[jn->other].procs; pn; pn = pn->next) 775 if (WIFSTOPPED(pn->status)) 776 break; 777 778 if (pn) { (gdb) p pn $3 = (struct process *) 0xbfbfd630 (gdb) p jobtab $2 = {{gleader = 0, other = 0, stat = 0, pwd = 0x0, procs = 0x0, filelist = 0x0, stty_in_env = 0, ty = 0x0}, {gleader = 12603, other = 12650, stat = 499, pwd = 0x80e8460 "/home/jos", procs = 0x80c2b00, filelist = 0x0, stty_in_env = 0, ty = 0x80c8580}, {gleader = 0, other = 0, stat = 0, pwd = 0x0, procs = 0x0, filelist = 0x0, stty_in_env = 0, ty = 0x0} } (gdb) p jn $7 = 0x80bb200 (gdb) p jn->other $8 = 12650 (gdb) p jobtab[jn->other] Cannot access memory at address 0x811df20. (gdb) Anyone have suggestions regarding things I can try in order to track down this problem? -- Jos Backus _/ _/_/_/ "Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/ _/ Jos.Backus@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer;