GNU bug report logs - #43395
28.0.50; memory leak

Previous Next

Full log

Message #27 received at 43395 <at> debbugs.gnu.org (full text, mbox):

From: Madhu <enometh <at> meer.net>
To: eliz <at> gnu.org
Cc: 43395 <at> debbugs.gnu.org, bugs <at> gnu.support
Subject: Re: bug#43395: memory leaks
Date: Wed, 11 Nov 2020 01:59:10 +0530 (IST)

*  Eli Zaretskii <eliz <at> gnu.org> <83k0ut2pv6.fsf <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.