From: James Kirkpatrick <jimkirk@uwyo.edu>
To: Bart Schaefer <schaefer@candle.brasslantern.com>
Cc: zsh-workers@sunsite.auc.dk, Susan L Hanna <hanna@uwyo.edu>
Subject: Re: zsh 3.0.7 hogs memory
Date: Tue, 30 Nov 1999 08:42:43 -0700 (MST) [thread overview]
Message-ID: <Pine.GSO.4.10.9911300839310.20454-100000@asuwlink.uwyo.edu> (raw)
In-Reply-To: <991124053547.ZM327@candle.brasslantern.com>
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
next prev parent reply other threads:[~1999-11-30 15:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-11-23 18:08 "getopts" bugs and bad interactions with "shift" Bart Schaefer
1999-11-23 18:22 ` Adam Spiers
1999-11-23 21:40 ` Bart Schaefer
1999-11-23 22:17 ` zsh 3.0.7 hogs memory James Kirkpatrick
1999-11-24 5:35 ` Bart Schaefer
1999-11-24 16:25 ` James Kirkpatrick
1999-11-30 15:42 ` James Kirkpatrick [this message]
1999-11-30 16:03 ` Bart Schaefer
1999-11-23 20:36 ` "getopts" bugs and bad interactions with "shift" Zefram
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.GSO.4.10.9911300839310.20454-100000@asuwlink.uwyo.edu \
--to=jimkirk@uwyo.edu \
--cc=hanna@uwyo.edu \
--cc=schaefer@candle.brasslantern.com \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).