From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16718 invoked from network); 2 Feb 2000 16:11:49 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 2 Feb 2000 16:11:49 -0000 Received: (qmail 14800 invoked by alias); 2 Feb 2000 16:11:43 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9533 Received: (qmail 14791 invoked from network); 2 Feb 2000 16:11:41 -0000 From: "Bart Schaefer" Message-Id: <1000202161136.ZM7024@candle.brasslantern.com> Date: Wed, 2 Feb 2000 16:11:36 +0000 In-Reply-To: <200002021530.QAA11346@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: Problems with trap handling?" (Feb 2, 4:30pm) References: <200002021530.QAA11346@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: Problems with trap handling? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Feb 2, 4:30pm, Sven Wischnowsky wrote: } Subject: Re: Problems with trap handling? } } James Kirkpatrick wrote: } } > I've slowly (too slowly!) been working with Bart Schaefer since around } > November to determine the nature of a loop that occurs if you turn on } > history files. It appears that (for example) a disconnect (hangup) causes } > zsh to loop in a manner where it consumes all available memory, severely } > impacting other users, until it presumably finally aborts. Putting a } > TRAPHUP () { exit 1 } } > works around the problem but I need to try a patch Bart sent me as well. } } Hm, I think I vaguely remember the problem you described (unless you } never posted it to the list, in which case I vaguely remember } something completely different). Dunno if it has anything to do with } the bugs I'm trying to fight... (but I don't think so, I would need to } know where it hangs). It appears to be repeatedly calling a signal handler. I'm not able to reproduce the bug on my Linux box. Following is the patch to which James referred. It simply makes sure that zsh doesn't HUP itself when exiting. It seems like a reasonable enough precaution. Index: Src/signals.c =================================================================== @@ -540,7 +540,8 @@ if ((from_signal || i != thisjob) && (jobtab[i].stat & STAT_LOCKED) && !(jobtab[i].stat & STAT_NOPRINT) && !(jobtab[i].stat & STAT_STOPPED)) { - if (killpg(jobtab[i].gleader, SIGHUP) != -1) + if (jobtab[i].gleader != getpid() && + killpg(jobtab[i].gleader, SIGHUP) != -1) killed++; } if (killed) -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com