[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#43395: memory leaks
From: |
Madhu |
Subject: |
bug#43395: memory leaks |
Date: |
Wed, 11 Nov 2020 01:59:10 +0530 (IST) |
* 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.