From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3298 invoked from network); 30 Nov 1999 15:43:00 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 30 Nov 1999 15:43:00 -0000 Received: (qmail 25273 invoked by alias); 30 Nov 1999 15:42:51 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8823 Received: (qmail 25266 invoked from network); 30 Nov 1999 15:42:51 -0000 Date: Tue, 30 Nov 1999 08:42:43 -0700 (MST) From: James Kirkpatrick Subject: Re: zsh 3.0.7 hogs memory In-reply-to: <991124053547.ZM327@candle.brasslantern.com> To: Bart Schaefer Cc: zsh-workers@sunsite.auc.dk, Susan L Hanna Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Authentication-warning: asuwlink.uwyo.edu: jimkirk owned process doing -bs Bart, Of the three suggestions (attach dbx, add a TRAPHUP, recompile with patch) I tried the TRAPHUP and that does indeed seem to solve the problem. However, it seems more of an experiment than a true fix. Does this give you enough to work towards a proper fix, or should I do more to characterize the problem (e.g. try one of the other two suggestions)? Jim On Wed, 24 Nov 1999, Bart Schaefer wrote: > On Nov 23, 3:17pm, James Kirkpatrick wrote: > } Subject: zsh 3.0.7 hogs memory > } > } It usually seems to happen to people running Pine (4.10). My guess at > } this point is that they dial in, start pine, and then either disconnect or > } become disconnected. > } > } One other clue: This only started happening when I added the following to > } /etc/zshenv: > } > } export HISTSIZE=200 > } export HISTFILE=~/.zsh_history > } export SAVEHIST=200 > } > } Once I commented it out, the problem went away. SO, I'm suspicious of > } problems in exception handling (disconnect) with history files turned on. > > (I'm going to assume that by "exceptions" you mean "signals".) > > The relevant bits of code would be: > > signals.c: 464: handler() > builtin.c: 4761: zexit() > hist.c: 1502-1584: savehistfile() > and maybe > signals.c: 543: killrunjobs() > > The only thing I could guess that might be happening is: > > handler(), invoked on SIGHUP, calls zexit(), which calls killrunjobs(); > killrunjobs() finds a job with group leader the current shell, and sends > it a SIGHUP; this invokes handler() again, and we loop. > > Now, it *should* be the case that during the handling of a SIGHUP, any > additional SIGHUP is blocked. The only possible connection I can come > up with between this and savehistfile() is if the stdio operations that > savehistfile() is using are somehow unblocking the signal, which seems > *very* unlikely. > > You could attach dbx or gdb to one of the runaway processes (the smallest > one) and get a look at the stack. Or (less helpful) you could try trapping > the HUP signal by adding this to /etc/zshenv as well: > > TRAPHUP() { exit 1 } > > This will invoke zexit() in a slightly different way ("from_signal" will > be false) and should avoid the SIGHUP loop I described, if in fact that > is the problem. > > Or you could assume that's the problem and try this patch: > > 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) > > I'll be a bit concerned about other signal-handling issues if that really > does fix it, though. > > -- > Bart Schaefer Brass Lantern Enterprises > http://www.well.com/user/barts http://www.brasslantern.com