bug#43395: memory leaks

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 10 Nov 2020 17:22:46 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: 43395@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.