bug#43395: memory leaks

[Madhu <enometh@meer.net>]

*  Eli Zaretskii <eliz@gnu.org> <83k0ut2pv6.fsf@gnu.org>
Wrote on Tue, 10 Nov 2020 17:28:13 +0200

> This is expected, and is not a bug.
>
> 'shell-command' is intended for running non-interactive programs,
> those which produce output, but don't expect any input.  So it runs
> the sub-process with its standard input connected to the null device.
> Your program has a bug in that case: it doesn't detect the EOF
> condition on its standard input (to see that, invoke it as
> "./a.out < /dev/null").  So it loops indefinitely, with each iteration
> pumping the prompts into Emacs, which obediently collects that in a
> buffer, that grows and grows and grows, until it eats up all the
> available memory.  And evidently, you didn't configure your system to
> have resident size limitation on user processes, so instead of
> reporting "memory full", Emacs is allowed to eat up all your memory
> and swap.
>
> In short: don't do that.
>
> I see no bug here: Emacs cannot know in advance how much stuff will be
> emitted by the sub-process, and it cannot know how much memory it cqan
> swallow before OOMK will sporing into action.
>
> And, of course, this is unrelated to the problems being discussed in
> this bug report.

Sorry, yes - the memory is indeed freed up when *Shell Command Output*
is killed.  I was mistaken in thinking that the memory was not freed
up when all the buffers had been deleted.

Apologies.