Re: 3.0.6-pre-5 problem

Re: 3.0.6-pre-5 problem

[Sven Wischnowsky]

Jos Backus wrote:

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

(This fact irritates me mightily.)

Anyway, I couldn't reproduce it but there is no harm in adding some
security code to execpline(). I guess this will not apply cleanly to
3.0.6, though.

And, of course, I have 6819 applied (which fixed a problem with
suspending shell functions, although that problem didn't cause a
SEGV).


Bye
 Sven

diff -u os/exec.c Src/exec.c
--- os/exec.c	Thu Jun 24 14:03:58 1999
+++ Src/exec.c	Fri Jun 25 08:10:28 1999
@@ -904,15 +904,16 @@
 		    if (!jn->procs->next)
 			jn->gleader = mypgrp;
 
-		    for (pn = jobtab[jn->other].procs; pn; pn = pn->next)
-			if (WIFSTOPPED(pn->status))
-			    break;
+		    if (jn->stat & STAT_SUPERJOB) {
+			for (pn = jobtab[jn->other].procs; pn; pn = pn->next)
+			    if (WIFSTOPPED(pn->status))
+				break;
 
-		    if (pn) {
-			for (qn = jn->procs; qn->next; qn = qn->next);
-			qn->status = pn->status;
+			if (pn) {
+			    for (qn = jn->procs; qn->next; qn = qn->next);
+			    qn->status = pn->status;
+			}
 		    }
-
 		    jn->stat &= ~(STAT_DONE | STAT_NOPRINT);
 		    jn->stat |= STAT_STOPPED | STAT_CHANGED;
 		    printjob(jn, !!isset(LONGLISTJOBS), 1);

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

Re: 3.0.6-pre-5 problem

[Bart Schaefer]

On Jun 25,  8:22am, Sven Wischnowsky wrote:
} Subject: Re: 3.0.6-pre-5 problem
}
} Jos Backus wrote:
} > Interestingly, this backtrace looks quite different from the first one.
} 
} (This fact irritates me mightily.)

The backtrace isn't really all that different, it just dies sooner with
debugging enabled.

} Anyway, I couldn't reproduce it but there is no harm in adding some
} security code to execpline(). I guess this will not apply cleanly to
} 3.0.6, though.

I think this patch (6838) should NOT be applied, and we need a different
one instead.  Look here:

} -		    for (pn = jobtab[jn->other].procs; pn; pn = pn->next)
} -			if (WIFSTOPPED(pn->status))
} -			    break;
} +		    if (jn->stat & STAT_SUPERJOB) {
} +			for (pn = jobtab[jn->other].procs; pn; pn = pn->next)
} +			    if (WIFSTOPPED(pn->status))
} +				break;

When I run this on linux inside gdb, it crashes on jobtab[jn->other], and
no wonder ... jn->other is a *process id*.  jobtab[] is only 50 elements
long; in my case jn->other == 3819, which puts jobtab[jn->other] way out
in the middle of nowhere.

Now, I see from the comments in zsh.h that jn->other is sometimes supposed
to be a job number, and sometimes supposed to be a PID, which I think is
a really bad style of overloading ... but style aside, there appear to be
cases in execpline() where it's being treated as a subjob number when it
really is a process ID.

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

Re: 3.0.6-pre-5 problem

[Bart Schaefer]

On Jun 25,  8:22am, Sven Wischnowsky wrote:
} Subject: Re: 3.0.6-pre-5 problem
}
} And, of course, I have 6819 applied (which fixed a problem with
} suspending shell functions, although that problem didn't cause a
} SEGV).

It looks like the following hunk of 6819 fixes the crash by *not* assigning
a process ID to jn->other; however, the xterm still hangs ... I think zsh
may have sent a STOP signal to the xterm that is its parent.

@@ -959,10 +962,14 @@
 			close(synch[1]);
 			read(synch[0], &dummy, 1);
 			close(synch[0]);
-			jobtab[list_pipe_job].other = newjob;
-			jobtab[list_pipe_job].stat |= STAT_SUPERJOB;
-			jn->stat |= STAT_SUBJOB | STAT_NOPRINT;
-			jn->other = pid;
+			/* If this job has finished, we turn this into a
+			 * normal (non-super-) job. */
+			if (!(jn->stat & STAT_DONE)) {
+			    jobtab[list_pipe_job].other = newjob;
+			    jobtab[list_pipe_job].stat |= STAT_SUPERJOB;
+			    jn->stat |= STAT_SUBJOB | STAT_NOPRINT;
+			    jn->other = pid;
+			}
 			if (list_pipe || last1)
 			    killpg(jobtab[list_pipe_job].gleader, SIGSTOP);
 			break;

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

Re: 3.0.6-pre-5 problem

[Bart Schaefer]

On Jun 25,  9:17am, Bart Schaefer wrote:
} Subject: Re: 3.0.6-pre-5 problem
}
} [...]  I think zsh
} may have sent a STOP signal to the xterm that is its parent.

Yup, I can confirm this:

zagzig% Src/zsh -f
zagzig% echo $SHLVL
4
zagzig% Src/zsh -f
zagzig% echo $SHLVL
5
zagzig% mutt () {
function>       command mutt "$@"
function>       echotc rs
function> }
zagzig% mutt
zsh: suspended (signal)  Src/zsh -f
zagzig% echo $SHLVL
4

Zsh has just stopped its parent.  Naughty zsh.

(The above is -pre-5 with 6819 and 6824 applied.)

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

Re: 3.0.6-pre-5 problem

[Bart Schaefer]

On Jun 25,  4:29pm, Bart Schaefer wrote:
} Subject: Re: 3.0.6-pre-5 problem
}
} zsh(28198)-+-pstree(5173)
}            `-xterm(5161)---zsh(5162)---mutt(5164)
} 
} The top-level xterm case is now producing process trees exactly like
} the case where there's an intermediate zsh, but the parent zsh is still
} not ignoring the TSTP.
 
More information:  Fooling around with "gdbterm" (I posted it to zsh-users
a while back) I managed to get zsh to stop and resume again (though the
mutt process got orphaned).  When zsh came back and I typed "fg" to try to
resume mutt, I got "no job control in this shell" which is pretty strange
as there had been job control a moment before.

That indicates to me that, in this bit of code from execpline() we're going
through the third branch:

		    if ((pid = fork()) == -1) {
			/* ... */
		    }
		    else if (pid) {
			/* ... */
		    else {
			close(synch[0]);
			entersubsh(Z_ASYNC, 0, 0);
			if (jobtab[list_pipe_job].procs)
			    setpgrp(0L, mypgrp = jobtab[list_pipe_job].gleader);
			close(synch[1]);
			kill(getpid(), SIGSTOP);
			list_pipe = 0;
			list_pipe_child = 1;
			opts[INTERACTIVE] = 0;
			break;
		    }

Which of course is the one thing Sven hasn't tried patching yet ... but I'm
not sure WHY zsh is going through the third branch.  All of Sven's patches
have been to the second branch.

What's odd is that over in the 6860 "Re: PATCH: loop killing" thread, zsh
DOESN'T get the signal when it's supposed to.  Maybe Sven's got the cases
in which zsh takes the second and third branches, reversed?

Or maybe I'm just completely confused, which is entirely likely by now.

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

Re: 3.0.6-pre-5 problem

[Bart Schaefer]

On Jun 25,  2:52pm, Sven Wischnowsky wrote:
} Subject: Re: 3.0.6-pre-5 problem
}
} I could finally reproduce it when trying to look at it with strace,
} which finally opened my eyes (I would have needed a `ps j' output).

 PPID   PID  PGID   SID TTY TPGID  STAT  UID   TIME COMMAND
 5161  5162  5162  5162  p4  5162  T     674   0:00 Src/zsh -f 
 5162  5164  5162  5162  p4  5162  T     674   0:00 mutt 
28198  5165  5165 28198  p3  5165  R     674   0:00 ps j 
28198  5161  5161 28198  p3  5169  S       0   0:00 xterm -e Src/zsh -f 

zsh(28198)-+-pstree(5173)
           `-xterm(5161)---zsh(5162)---mutt(5164)

} It goes like this: Someone exec()s zsh without putting it into its own
} process group. Then we start the function and zsh executes external
} commands in its own process group.

The top-level xterm case is now producing process trees exactly like
the case where there's an intermediate zsh, but the parent zsh is still
not ignoring the TSTP.

} So, if we have agreed to use the kill-loop-patches, we'll have to make 
} sure that every decent interactive zsh with job-control runs in its
} own process group which is what the patch below does.

This is a good idea in any case.

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

Re: 3.0.6-pre-5 problem

[Peter Stephenson]

(I tried to reply to this several times before but it doesn't seem to have
worked, due to the @!$*! disk being full again.)

Sven Wischnowsky wrote:
> So, if we have agreed to use the kill-loop-patches, we'll have to make 
> sure that every decent interactive zsh with job-control runs in its
> own process group which is what the patch below does.

Does this have implications for sending signals from the Ctrl-Button1 menu
of an xterm, not that that ever worked for me anyway?

By the way, although this is totally unrelated, looking at this I
discovered that
  SHELL=/usr/bin/ksh xterm &
creates an xterm with terminal settings messed up.  Without the & it's OK.

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

Re: 3.0.6-pre-5 problem

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Jun 25, 11:38am, Sven Wischnowsky wrote:
> } Subject: Re: 3.0.6-pre-5 problem
> }
> } I hope this fixes it.
> 
> No such luck.  Here's "pstree" output:
> 
> zsh(28198)-+-pstree(4199)
>            |-xterm(4146)---zsh(4147)-+-mutt(4149)
>            |                         `-zsh(4153)
>            `-xterm(4191)---zsh(4192)---zsh(4194)---mutt(4196)
> 
> The first xterm (4146) I ran the "mutt" function directly from the top
> shell and then hit ^Z.  4149 and 4153 are both stopped; 4146 is blocked
> in wait4() which means that 4147 can't get any keystrokes (the xterm
> isn't feeding it) which is the hang that Jos sees.
> 
> The second xterm (4191) I ran a new zsh -f (4194) and then the "mutt"
> function; there, 4194 and 4196 are stopped.
> 
> Note that in the first case zsh created an extra dummy job, but in the
> second case it didn't.  This must have something to do with which process
> is the group leader.

(To Bart: I was doing it inside an xterm, but from a bash that ran
inside the xterm.)

I could finally reproduce it when trying to look at it with strace,
which finally opened my eyes (I would have needed a `ps j' output). It 
goes like this: Someone exec()s zsh without putting it into its own
process group. Then we start the function and zsh executes external
commands in its own process group. Then the user hits ^Z and all three 
of them receive the SIGTSTP. The external command is stopped, which is 
fine, zsh ignores it, which is better, and the parent of zsh happens
to not ignore it and stopt, which is deadly.

So, if we have agreed to use the kill-loop-patches, we'll have to make 
sure that every decent interactive zsh with job-control runs in its
own process group which is what the patch below does.

Ok. Since I still couldn't reproduce the exact original problem, I'd
be thankful for any response (*especially* if it's fixed).

Bye
 Sven

P.S.: Peter: 6838 should be superfluous, but I still like the look of 6848.

--- os/init.c	Thu Jun 24 19:00:56 1999
+++ Src/init.c	Fri Jun 25 14:41:12 1999
@@ -390,7 +390,16 @@
 #ifdef JOB_CONTROL
     /* If interactive, make the shell the foreground process */
     if (opts[MONITOR] && interact && (SHTTY != -1)) {
-	attachtty(GETPGRP());
+      /* Since we now sometimes execute programs in the process group
+       * of the parent shell even when using job-control, we have to
+       * make sure that we run in our own process group. Otherwise if
+       * we are called from a program that doesn't put us in our own
+       * group a SIGTSTP that we ignore might stop our parent process.
+       * Instead of the two calls below we once had:
+       *   attachtty(GETPGRP());
+       */
+	attachtty(getpid());
+	setpgrp(0L, 0L);
 	if ((mypgrp = GETPGRP()) > 0) {
 	    while ((ttpgrp = gettygrp()) != -1 && ttpgrp != mypgrp) {
 		sleep(1);

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

Re: 3.0.6-pre-5 problem

[Bart Schaefer]

On Jun 25, 11:38am, Sven Wischnowsky wrote:
} Subject: Re: 3.0.6-pre-5 problem
}
} I hope this fixes it.

No such luck.  Here's "pstree" output:

zsh(28198)-+-pstree(4199)
           |-xterm(4146)---zsh(4147)-+-mutt(4149)
           |                         `-zsh(4153)
           `-xterm(4191)---zsh(4192)---zsh(4194)---mutt(4196)

The first xterm (4146) I ran the "mutt" function directly from the top
shell and then hit ^Z.  4149 and 4153 are both stopped; 4146 is blocked
in wait4() which means that 4147 can't get any keystrokes (the xterm
isn't feeding it) which is the hang that Jos sees.

The second xterm (4191) I ran a new zsh -f (4194) and then the "mutt"
function; there, 4194 and 4196 are stopped.

Note that in the first case zsh created an extra dummy job, but in the
second case it didn't.  This must have something to do with which process
is the group leader.

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

Re: 3.0.6-pre-5 problem

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Jun 25,  9:17am, Bart Schaefer wrote:
> } Subject: Re: 3.0.6-pre-5 problem
> }
> } [...]  I think zsh
> } may have sent a STOP signal to the xterm that is its parent.
> 
> Yup, I can confirm this:
> 
> zagzig% Src/zsh -f
> zagzig% echo $SHLVL
> 4
> zagzig% Src/zsh -f
> zagzig% echo $SHLVL
> 5
> zagzig% mutt () {
> function>       command mutt "$@"
> function>       echotc rs
> function> }
> zagzig% mutt
> zsh: suspended (signal)  Src/zsh -f
> zagzig% echo $SHLVL
> 4
> 
> Zsh has just stopped its parent.  Naughty zsh.

Err, itself, right?

That was a hint... (I still wonder why I can't reproduce it, though).

I hope this fixes it. It's the only place where a parent shell sends a 
SIGSTOP and, yes, it's good to have that extra test there -- it means
roughly that we don't need to suspend the beginning of a pipeline if
there is no such beginning -- exactly what happens when suspending a
function.


Bye
 Sven

--- os/exec.c	Fri Jun 25 10:06:02 1999
+++ Src/exec.c	Fri Jun 25 11:32:57 1999
@@ -966,7 +966,7 @@
 			close(synch[1]);
 			read(synch[0], &dummy, 1);
 			close(synch[0]);
-			/* If this job has finished, we turn this into a
+			/* If this job has finished, we leave it as a
 			 * normal (non-super-) job. */
 			if (!(jn->stat & STAT_DONE)) {
 			    jobtab[list_pipe_job].other = newjob;
@@ -974,7 +974,7 @@
 			    jn->stat |= STAT_SUBJOB | STAT_NOPRINT;
 			    jn->other = pid;
 			}
-			if (list_pipe || last1)
+			if ((list_pipe || last1) && jobtab[list_pipe_job].procs)
 			    killpg(jobtab[list_pipe_job].gleader, SIGSTOP);
 			break;
 		    }

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

Re: 3.0.6-pre-5 problem

[Sven Wischnowsky]

Bart Schaefer wrote:

> } Anyway, I couldn't reproduce it but there is no harm in adding some
> } security code to execpline(). I guess this will not apply cleanly to
> } 3.0.6, though.
> 
> I think this patch (6838) should NOT be applied, and we need a different
> one instead.  Look here:

Have you tried it with 6819 and 6824 (I forgot to mention the latter, 
sorry)? With them (and pws-23) I can't reproduce it and both of them
could influence it (especially 6824, which fixed a bug with suspending 
functions that garbled the job-table entry).


Bye
 Sven


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

Re: 3.0.6-pre-5 problem

[Jos Backus]

Fwiw, zsh-3.1.5-pws-23 has the same problem:

---Mutt: =inbox [Msgs:449
13M]---(threads/date)-------------------------(end)---
^Z
zsh: 8532 segmentation fault (core dumped)  ./Src/zsh
Caught Hangup...  Exiting.
jos:/usr/local/src/zsh-3.1.5-pws-23% gdb Src/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  0x805631d in execpline (l=0xbfbfdae4, how=672490182, last1=134635392)
    at exec.c:904
904                         for (pn = jobtab[jn->other].procs; pn; pn = pn->next
)
(gdb) list
899
900                         curjob = newjob;
901                         DPUTS(!list_pipe_pid, "invalid list_pipe_pid");
902                         addproc(list_pipe_pid, list_pipe_text);
903
904                         for (pn = jobtab[jn->other].procs; pn; pn = pn->next
)
905                             if (WIFSTOPPED(pn->status))
906                                 break;
907
908                         if (pn) {
(gdb) p jn->other
$1 = 8533
(gdb) p jobtab[jn->other].procs
Cannot access memory at address 0x8980cb0.
(gdb) 

Btw, this is on

FreeBSD jos.bugworks.com 4.0-CURRENT FreeBSD 4.0-CURRENT #: Mon Jun 21 19:49:17 CEST 1999     jos@jos.bugworks.com:/usr/src/sys/compile/JOS  i386

-- 
Jos Backus                          _/ _/_/_/  "Reliability means never
                                   _/ _/   _/   having to say you're sorry."
                                  _/ _/_/_/             -- D. J. Bernstein
                             _/  _/ _/    _/
Jos.Backus@nl.origin-it.com  _/_/  _/_/_/      use Std::Disclaimer;

Re: 3.0.6-pre-5 problem

[Jos Backus]

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} <repeats 48 times>}
(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;

3.0.6-pre-5 problem

[Jos Backus]

	Hi,

Because of the outdated system ncurses FreeBSD uses, I am using the following
function:

mutt () {
	command mutt "$@"
	echotc rs
}

With 3.0.6-pre-5 something odd is happening:

hal:~% xterm &!

---Mutt: =inbox [Msgs:726 New:10 Flag:1 Inc:11 5.1M]---(threads/date)---(end)---
^Z	<background mutt>
zsh: 685 suspended (signal)  mutt | 
zsh: 686 running             mutt
hal:~% fg
q	<quit mutt>
---Mutt: =inbox [Msgs:727 New:11 Flag:1 Inc:11 5.1M]---(threads/date)---(99%)---

<xterm ``hangs'', no prompt is output>

There's a core file, too:

hal:~jos# 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"...
(no debugging symbols found)...
Core was generated by `zsh'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libtermcap.so.2...(no debugging symbols found)...
done.
Reading symbols from /usr/lib/libc.so.3...(no debugging symbols found)...done.
Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...
done.
#0  0x8063943 in makerunning ()
(gdb) where
#0  0x8063943 in makerunning ()
#1  0x806398d in makerunning ()
#2  0x806398d in makerunning ()
#3  0x804b126 in bin_fg ()
#4  0x804a558 in execbuiltin ()
#5  0x80576fb in execcmd ()
#6  0x8055b5b in execpline2 ()
#7  0x805561f in execpline ()
#8  0x805530e in execlist ()
#9  0x8061ad8 in loop ()
#10 0x8061951 in main ()
#11 0x8049f61 in _start ()
(gdb) 

This doesn't happen when I call mutt directly (using ``command mutt'').

This looks like a zsh problem that may have been introduced with pre-5.

I can supply details if needed.

Thanks,
-- 
Jos Backus                          _/ _/_/_/  "Reliability means never
                                   _/ _/   _/   having to say you're sorry."
                                  _/ _/_/_/             -- D. J. Bernstein
                             _/  _/ _/    _/
Jos.Backus@nl.origin-it.com  _/_/  _/_/_/      use Std::Disclaimer;