GNU bug report logs - #43395
28.0.50; memory leak

Previous Next

Package: emacs;

Reported by: Madhu <enometh <at> meer.net>

Date: Mon, 14 Sep 2020 05:37:01 UTC

Severity: normal

Merged with 43389, 43876, 44666

Found in version 28.0.50

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: enometh <at> meer.net, 43395 <at> debbugs.gnu.org
Subject: bug#43395: memory leaks
Date: Tue, 10 Nov 2020 17:28:13 +0200
> Date: Tue, 10 Nov 2020 17:22:46 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: 43395 <at> debbugs.gnu.org
> 
> > #+BEGIN_SRC
> > $ cat > f.c
> > #include <stdio.h>
> > int
> > main()
> > {
> >   char c = ' ';
> >   while (c != 'q' && c != 'Q')
> >     {
> >       fprintf(stdout, "Press q then enter to quit: ");
> >       c = fgetc(stdin);
> >     }
> >   return 0;
> > }
> > ^D
> > 
> > $ gcc f.c
> > $ emacs -Q
> > #+END_SRC
> > 
> > M-x shell-command ./a.out
> > 
> > Then the process hangs. But Emacs' memory grows unbounded.

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.




This bug report was last modified 4 years and 58 days ago.

Previous Next


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