From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6635 invoked from network); 29 Jun 1999 07:35:37 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 29 Jun 1999 07:35:37 -0000 Received: (qmail 25862 invoked by alias); 29 Jun 1999 07:35:26 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6905 Received: (qmail 25855 invoked from network); 29 Jun 1999 07:35:24 -0000 From: "Bart Schaefer" Message-Id: <990629073444.ZM16631@candle.brasslantern.com> Date: Tue, 29 Jun 1999 07:34:44 +0000 In-Reply-To: <199906290656.IAA18345@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "PATCH: that execution stuff" (Jun 29, 8:56am) References: <199906290656.IAA18345@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (5.0.0 30July97) To: Sven Wischnowsky , zsh-workers@sunsite.auc.dk Subject: Re: PATCH: that execution stuff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 29, 8:56am, Sven Wischnowsky wrote: } Subject: PATCH: that execution stuff } } This tries to get the always-pgrp-behavior back without losing the } other things that were fixed in the meanwhile. Now please test your } favorite execution bugs everyone and tell me what does not work. This gets exactly to where I got, and no farther. The test case is the same as for the original problem reported by Jos Backus; the failure is as I described in 6883: Suspend the function, then bring it back into the foreground, and bin_fg() passes zsh's PID to attachtty() as the process group, which means mutt gets a SIGTTIN as soon as you type. And then when you try to bring it back into the foreground yet again, the wrong thing gets SIGCONT'd and zsh ends up waiting in sigsuspend() for a job that's never going to signal it. Trying to debug this the other night I got into a state where zsh tried to bring jobtab[1] into the foreground but everything in the job table was zeroed, which produced a crash. Another time bin_fg() selected [1] but the entry with the correct gleader was jobtab[2]. Something somewhere is completely messed up with respect to when/whether to delete a job, but it's almost impossible to debug because if you set breakpoints the subshells crash and if you attach with gdb at the wrong time some of the signals get completely thrown away. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com