[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "HISTSIZE=999999999" cause bash failure after lastest upgrade

From: Klaas van Schelven
Subject: Re: "HISTSIZE=999999999" cause bash failure after lastest upgrade
Date: Wed, 16 Aug 2017 15:34:44 +0200

Hello Chet,

I'm replying to a 2-year old bug; I think it's still relevant.

subject: "HISTSIZE=999999999" cause bash failure after lastest upgrade
link: https://lists.gnu.org/archive/html/bug-bash/2016-09/msg00113.html
text bellow:

> > Bash Version: 4.4
> > Patch Level: 0
> > Release Status: release
> >
> > Description:
> >       I use a huge value for HISTSIZE (=999999999) to enable infinite
> >       history items. The actural size of ~/.bash_history is only 4MB
> >       Everything worked fine before the lastest upgrade. Now bash refuse
> >       me to login due to memory allocation failure. After choosing
> >       a smaller HISTSIZE, bash still eatup too much unnesssary memory.
> >
> > Repeat-By:
> >       open a workable terminal with small HISTSIZE setting,
> >       $ echo HISTSIZE=999999999 > ~/test.rc
> >       $ bash --rcfile ~/test.rc
> >         bash: xmalloc: cannot allocate 8000000008 bytes (114688 bytes
> > allocated)
> Since you've specified the desired history size, bash tries to allocate
> enough entries to hold all of the entries.  The assumption is that this
> will reduce the number of allocations/reallocations and the number of
> times the history list has to be copied as it's reallocated.  I suppose
> I should cap the maximum value for which that occurs instead of trusting
> the supplied max number of entries.
> Chet

I'm on GNU bash, version 4.4.5(1) myself.

I'm not sure the solution mentioned above is sufficient to solve all
relevant variant problems caused by the pre-allocation of the memory.

In particular, I ran into this myself with a value of HISTSIZE=100000000 (8
zeros), which gobbled up approximately 1GB of memory per bash instance.

Experimenting a bit led to  HISTSIZE=1000000000 (9 zeros), which was enough
to crash and is apparently still under this cap (if that is implemented in
4.4.5(1) at all).

The fall out of this problem is potentially quite large, e.g. lockout from
remote systems if bash is the default installed shell and the only user
with access has some arbitrarily large HISTSIZE configured.

Aside from this particular scenario I would question the trade-off of
pre-allocation more generally. Besides the waste of memory, even for
non-crashing cases, there's also a performance penalty on startup (in the
1GB case mentioned above, this was visible with the naked eye).

Until not too long ago the option of setting -1 as a value for HISTSIZE was
not available (bash 4.3 introduced it) , so I imagine instances of very
large values are not entirely uncommon.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]