As of 4.4, bash tries to allocate enough memory to cover as many entries as are specified by HISTFILESIZE. Some people set this to an arbitrarily large value, in which case potentially dire results will ensue after upgrading to 4.4. Here's a patch from Chet Ramey: http://lists.gnu.org/archive/html/bug-bash/2016-10/msg00010.html A plausible worst-case scenario would be that someone upgrades a remote system, only to find that they can no longer log in with ssh. Therefore, I recommend applying said patch by way of a revision bump. Presumably, it will be addressed in bash44-001, whenever that lands.
Created attachment 450060 [details, diff] Patch to clamp the amount of memory initially allocated for history
commit eb4d79382613c3fa33a2375ba75f3b4f8b67eae4 Author: Lars Wendler <polynomial-c@gentoo.org> Date: Thu Oct 13 10:29:59 2016 app-shells/bash: Revbump to fix bug #597006 Package-Manager: portage-2.3.2 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> Fixed in app-shells/bash-4.4-r1
that patch is against readline, and released versions of bash don't build against the bundled copy, so putting the patch into bash doesn't help :) fixed here: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4b0bd0d1d7636f79c4c1a65ab280c7f9009ff26e https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6a6d6915dfc68f4a67a7e8c03265d9e02ed39425
(In reply to SpanKY from comment #3) > that patch is against readline, and released versions of bash don't build > against the bundled copy, so putting the patch into bash doesn't help :) I'm embarrassed to have overlooked that. Thanks, SpanKY.