From: "Vitaly Zuevsky" <vitaly.zuevsky@gmail.com>
To: 'Andrej Shadura' <andrew@shadura.me>,
953421@bugs.debian.org, dash@vger.kernel.org
Cc: 'Debian Bug Tracking System' <submit@bugs.debian.org>
Subject: RE: Bug#953421: dash: Resident Set Size growth is unbound (memory leak) on an infinite shell loop
Date: Sun, 29 Mar 2020 18:54:14 +0100 [thread overview]
Message-ID: <07ce01d605f3$103f1610$30bd4230$@gmail.com> (raw)
In-Reply-To: <CACujMDPfs5mJs8CVaxqM6wkCRANYQ71wTUkvHiNvOg+MPSTECQ@mail.gmail.com>
I have now fixed this bug locally.
The leak is in jobtab array (jobs.c). I concluded that the most logical approach would be eliminating inconsistency between makejob() and dowait() functions. My fix in a forked repo:
https://salsa.debian.org/psvz-guest/dash/-/commit/5e3ea90cb3355d1308c482661a471883d36af5e7
I suspect that imbalance between allocating and freeing jobtab slots was introduced at evolving SIGCHLD handling, because I can see two waitforjob() calls, wherein the first call could wait for both done jobs and gotsigchld is set. At the second call, gotsigchld is cleared and waitforjob() does nothing. So 1 of 2 jobtab slots goes astray.
Simplified bug repro steps:
Script
-------
while true
do
true &
sleep .1
done
Execution
-------------
# dash Script &
You can now observe resident set size (RSS) is bumped every several seconds:
# ps aux |grep 'RSS\|dash'
What do I do to have it peer-reviewed and, potentially, merged into mainline?
Cheers,
Vitaly
----------fixDetails:
Function makejob() calls freejob() when appropriate.
Specifically, it detects a free slot in jobtab array by this condition:
(jp->state != JOBDONE || !jp->waited)
The problem is that dowait() never sets waited flag together with JOBDONE state.
Consequently, jobtab may leak: repro steps are provided in a bug report #953421.
One solution could be not relying on waited flag at all, i.e. converting
the makejob()'s condition into (jp->state != JOBDONE). As an alternative,
I am setting waited flag in dowait().
next parent reply other threads:[~2020-03-29 17:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <158376996556.31988.8584094104007124674.reportbug@ec2-34-240-101-198.eu-west-1.compute.amazonaws.com>
[not found] ` <CACujMDPfs5mJs8CVaxqM6wkCRANYQ71wTUkvHiNvOg+MPSTECQ@mail.gmail.com>
2020-03-29 17:54 ` Vitaly Zuevsky [this message]
2020-03-29 19:06 ` Bug#953421: dash: Resident Set Size growth is unbound (memory leak) on an infinite shell loop Harald van Dijk
2020-03-29 22:07 ` Jilles Tjoelker
2020-03-29 23:07 ` Harald van Dijk
2020-03-31 19:07 ` Vitaly Zuevsky
2020-03-31 21:04 ` Harald van Dijk
2020-04-02 13:18 ` Vitaly Zuevsky
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='07ce01d605f3$103f1610$30bd4230$@gmail.com' \
--to=vitaly.zuevsky@gmail.com \
--cc=953421@bugs.debian.org \
--cc=andrew@shadura.me \
--cc=dash@vger.kernel.org \
--cc=submit@bugs.debian.org \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox