Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: chen liu <chen.liu.opensource@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Re: Memory continusely increase
Date: Wed, 26 Dec 2018 19:01:23 +0800
Lines: 77
Approved: bug-bash@gnu.org
Message-ID: <mailman.6303.1545822465.1284.bug-bash@gnu.org>
References: <1545199834453-0.post@n7.nabble.com> <8ba9e82f-020a-3bf5-87c5-ce250f89e269@case.edu> <CACJSzi1GZxS_4=Tw2tXauaokW7C1dTOW0pPFWWhuhA1bX5gdjw@mail.gmail.com> <20181226053501.GA31843@debian.vc.shawcable.net>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
To: chen liu <chen.liu.opensource@gmail.com>, chet.ramey@case.edu, bug-bash <Bug-bash@gnu.org>
Envelope-to: Bug-bash@gnu.org
In-Reply-To: <20181226053501.GA31843@debian.vc.shawcable.net>
Precedence: list
Xref: csiph.com gnu.bash.bug:14953

Eduardo A. Bustamante L=C3=B3pez <dualbus@gmail.com> =E4=BA=8E2018=E5=B9=B4=
12=E6=9C=8826=E6=97=A5=E5=91=A8=E4=B8=89 =E4=B8=8B=E5=8D=881:35=E5=86=99=E9=
=81=93=EF=BC=9A
>
> On Mon, Dec 24, 2018 at 10:51:00AM +0800, chen liu wrote:
> > Chet Ramey <chet.ramey@case.edu> =E4=BA=8E2018=E5=B9=B412=E6=9C=8822=E6=
=97=A5=E5=91=A8=E5=85=AD =E4=B8=8A=E5=8D=8812:51=E5=86=99=E9=81=93=EF=BC=9A
> (...)
> > > What is the hard limit on the number of processes for a process start=
ed in
> > > this environment? (The value of `ulimit -n'.)
>
> Ah, interesting. Thanks for the pointer Chet.
>
> (...)
> > Below is all of the values of the bash ulimit optionals, this issue
> > present in this environment
> > ----------------------------------------------------------------------
> > root@localhost:/root> cat ulimit.txt
> (...)
> > max user processes (-u) 516046
> > virtual memory (kbytes, -v) unlimited
> > file locks (-x) unlimited
> > -----------------------------------------------------------------------=
----
> > But found change the -u optionals value through the ( ulimit -u 1024)
> > will let this issue disapeared.
>
> As you probably found out already, the changes between 4.3 and 4.4 that m=
ake
> this issue "disappear" are related to how bash stores the exit status of
> child processes.
>
> The threads that prompted this change provide some insight:
>
> - https://lists.gnu.org/archive/html/bug-bash/2015-04/msg00069.html

Thanks for you support:)
The change has introduced in bash since bash-4.4-alpha. This patch
fixed this issue.
And the note in Changelog
---------------------------------------------------------------------------=
---------------------------
 jobs.c
       - delete_job: only add J_ASYNC (and not J_FOREGROUND) jobs to the
         bgpids array, since Posix says shells only need to save the status
         of async jobs.  Report and fix from John Fremlin <john@fb.com>
---------------------------------------------------------------------------=
------------------------------

Thanks,
Chen.


> - http://lists.gnu.org/archive/html/bug-bash/2015-04/msg00075.html
>
> And the note in the changelog:
>
> http://git.savannah.gnu.org/cgit/bash.git/tree/CWRU/old-changelogs/CWRU.c=
hlog.v15?h=3Dab8ded9c30b51a6bc0c8145553263da044b565ea#n9811
>
> > jobs.[ch]
> >       - bgpids: new implementation from a patch from John Fremlin
> >         <john@fb.com>, uses an array for the list of the last CHILD_MAX
> >         terminated background pids, and a separate hash table to search=
 it.
> >         The storage can be freed as a unit, and the size of the hash ta=
ble
> >         (currently 4096) is independent of the size of the bgpids table
>
> http://git.savannah.gnu.org/cgit/bash.git/tree/CHANGES-4.4?h=3Dab8ded9c30=
b51a6bc0c8145553263da044b565ea#n220
>
> > e.  There is a new implementation of the code that saves the last CHILD=
_MAX
> >     exited background pids so their status can be queried later.