From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: James Kirkpatrick <jimkirk@uwyo.edu>, zsh-workers@sunsite.auc.dk
Cc: Susan L Hanna <hanna@uwyo.edu>
Subject: Re: zsh 3.0.7 hogs memory
Date: Wed, 24 Nov 1999 05:35:47 +0000 [thread overview]
Message-ID: <991124053547.ZM327@candle.brasslantern.com> (raw)
In-Reply-To: <Pine.GSO.4.10.9911231507030.4302-100000@asuwlink.uwyo.edu>
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-24 5:36 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 [this message]
1999-11-24 16:25 ` James Kirkpatrick
1999-11-30 15:42 ` James Kirkpatrick
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=991124053547.ZM327@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=hanna@uwyo.edu \
--cc=jimkirk@uwyo.edu \
--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).