Bug or not? printf allocates buffer & never frees it

Bug or not? printf allocates buffer & never frees it

[Ian Pilcher]

Fedora 33 with glibc-2.32-4.fc33.x86_64.

Simple reproducer:

  #include <mcheck.h>
  #include <stdio.h>

  int main(void)
  {
	mtrace();
	printf("%d\n", 0);
	muntrace();
	return 0;
  }

Running with MALLOC_TRACE set shows:

  Memory not freed:
  -----------------
             Address     Size     Caller
  0x0000000000e1d690    0x400  at 0x7f19511d2934

The trace file shows that the memory was allocated by
_IO_file_doallocate:

  = Start
  @ /lib64/libc.so.6:(_IO_file_doallocate+0x94)[0x7f19511d2934] + 
0xe1d690 0x400
  = End

And gdb shows that _IO_file_doallocate is called from printf:

  #0  0x00007ffff7e578a0 in _IO_file_doallocate () from /lib64/libc.so.6
  #1  0x00007ffff7e662f0 in _IO_doallocbuf () from /lib64/libc.so.6
  #2  0x00007ffff7e65488 in __GI__IO_file_overflow () from /lib64/libc.so.6
  #3  0x00007ffff7e64536 in __GI__IO_file_xsputn () from /lib64/libc.so.6
  #4  0x00007ffff7e4f269 in __vfprintf_internal () from /lib64/libc.so.6
  #5  0x00007ffff7e3b2af in printf () from /lib64/libc.so.6
  #6  0x0000000000401163 in main () at leak.c:11

Multiple calls to printf don't leak additional memory, so this isn't
really a problem (other than the time wasted by folks hunting memory
leaks).

Is this considered a bug?

-- 
========================================================================
                  In Soviet Russia, Google searches you!
========================================================================

Re: Bug or not? printf allocates buffer & never frees it

[Florian Weimer]

* Ian Pilcher via Libc-help:

> Fedora 33 with glibc-2.32-4.fc33.x86_64.
>
> Simple reproducer:
>
>  #include <mcheck.h>
>  #include <stdio.h>
>
>  int main(void)
>  {
> 	mtrace();
> 	printf("%d\n", 0);
> 	muntrace();
> 	return 0;
>  }
>
> Running with MALLOC_TRACE set shows:
>
>  Memory not freed:
>  -----------------
>             Address     Size     Caller
>  0x0000000000e1d690    0x400  at 0x7f19511d2934

> Is this considered a bug?

What happens if you remove the muntrace call?  I suspect you see this
leak because you are specifically telling glibc not to log the
deallocation.

Thanks,
Florian

Re: Bug or not? printf allocates buffer & never frees it

[Ian Pilcher]

On 3/17/21 12:45 PM, Florian Weimer via Libc-help wrote:
> What happens if you remove the muntrace call?  I suspect you see this
> leak because you are specifically telling glibc not to log the
> deallocation.

You are correct.  Blindingly obvious in retrospect.

Thanks!

-- 
========================================================================
                  In Soviet Russia, Google searches you!
========================================================================

Re: Bug or not? printf allocates buffer & never frees it

[Godmar Back]

On Wed, Mar 17, 2021 at 1:46 PM Florian Weimer via Libc-help
<libc-help@sourceware.org> wrote:
>
> What happens if you remove the muntrace call?  I suspect you see this
> leak because you are specifically telling glibc not to log the
> deallocation.
>

Since you called this a `leak`, may I ask a question that is
tangentially related?

Is GNU libc designed to be used in environments that do not deallocate
all memory upon exit(), i.e., environments that can call exit()
multiple times without being provided with a fresh heap each time?  I
understand ISO C allows this and POSIX is quiet on this specific
issue. Is complete deallocation of one-time buffers before exit() a
design goal of GNU libc?

 - Godmar

Re: Bug or not? printf allocates buffer & never frees it

[Florian Weimer]

* Godmar Back:

> Is GNU libc designed to be used in environments that do not deallocate
> all memory upon exit(), i.e., environments that can call exit()
> multiple times without being provided with a fresh heap each time?  I
> understand ISO C allows this and POSIX is quiet on this specific
> issue. Is complete deallocation of one-time buffers before exit() a
> design goal of GNU libc?

Not really.  None of the currently supported targets behave in that way.
We have __libc_freeres to clean up *after* exit (and atexit handlers
etc.), but it only exists for leak debuggers.  valgrind can call it, for
example, and we also call it in mtrace mode.  It's also a bit of a
reasonable effort thing: there are allocations we currently do not free,
particularly around dlopen.

Thanks,
Florian

Re: Bug or not? printf allocates buffer & never frees it

[Konstantin Kharlamov]

On Wed, 2021-03-17 at 12:30 -0500, Ian Pilcher via Libc-help wrote:
> Fedora 33 with glibc-2.32-4.fc33.x86_64.
> 
> Simple reproducer:
> 
>   #include <mcheck.h>
>   #include <stdio.h>
> 
>   int main(void)
>   {
>         mtrace();
>         printf("%d\n", 0);
>         muntrace();
>         return 0;
>   }
> 
> Running with MALLOC_TRACE set shows:
> 
>   Memory not freed:
>   -----------------
>              Address     Size     Caller
>   0x0000000000e1d690    0x400  at 0x7f19511d2934
> 
> The trace file shows that the memory was allocated by
> _IO_file_doallocate:
> 
>   = Start
>   @ /lib64/libc.so.6:(_IO_file_doallocate+0x94)[0x7f19511d2934] + 
> 0xe1d690 0x400
>   = End
> 
> And gdb shows that _IO_file_doallocate is called from printf:
> 
>   #0  0x00007ffff7e578a0 in _IO_file_doallocate () from /lib64/libc.so.6
>   #1  0x00007ffff7e662f0 in _IO_doallocbuf () from /lib64/libc.so.6
>   #2  0x00007ffff7e65488 in __GI__IO_file_overflow () from /lib64/libc.so.6
>   #3  0x00007ffff7e64536 in __GI__IO_file_xsputn () from /lib64/libc.so.6
>   #4  0x00007ffff7e4f269 in __vfprintf_internal () from /lib64/libc.so.6
>   #5  0x00007ffff7e3b2af in printf () from /lib64/libc.so.6
>   #6  0x0000000000401163 in main () at leak.c:11
> 
> Multiple calls to printf don't leak additional memory, so this isn't
> really a problem (other than the time wasted by folks hunting memory
> leaks).
> 
> Is this considered a bug?
> 

Hi! I'm not very acknowledged with the output, am I right that printf calls "deallocate", however the actual memory is still being held and not returned to the kernel? If yes, then you're likely stumbled upon this bug https://sourceware.org/bugzilla/show_bug.cgi?id=27103 See also this gigantic thread https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45200