* Bug or not? printf allocates buffer & never frees it
@ 2021-03-17 17:30 Ian Pilcher
2021-03-17 17:45 ` Florian Weimer
2021-03-17 19:23 ` Konstantin Kharlamov
0 siblings, 2 replies; 6+ messages in thread
From: Ian Pilcher @ 2021-03-17 17:30 UTC (permalink / raw)
To: 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
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!
========================================================================
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug or not? printf allocates buffer & never frees it
2021-03-17 17:30 Bug or not? printf allocates buffer & never frees it Ian Pilcher
@ 2021-03-17 17:45 ` Florian Weimer
2021-03-17 20:29 ` Ian Pilcher
2021-03-17 20:47 ` Godmar Back
2021-03-17 19:23 ` Konstantin Kharlamov
1 sibling, 2 replies; 6+ messages in thread
From: Florian Weimer @ 2021-03-17 17:45 UTC (permalink / raw)
To: Ian Pilcher via Libc-help; +Cc: Ian Pilcher
* 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug or not? printf allocates buffer & never frees it
2021-03-17 17:30 Bug or not? printf allocates buffer & never frees it Ian Pilcher
2021-03-17 17:45 ` Florian Weimer
@ 2021-03-17 19:23 ` Konstantin Kharlamov
1 sibling, 0 replies; 6+ messages in thread
From: Konstantin Kharlamov @ 2021-03-17 19:23 UTC (permalink / raw)
To: Ian Pilcher, libc-help
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug or not? printf allocates buffer & never frees it
2021-03-17 17:45 ` Florian Weimer
@ 2021-03-17 20:29 ` Ian Pilcher
2021-03-17 20:47 ` Godmar Back
1 sibling, 0 replies; 6+ messages in thread
From: Ian Pilcher @ 2021-03-17 20:29 UTC (permalink / raw)
To: libc-help
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!
========================================================================
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug or not? printf allocates buffer & never frees it
2021-03-17 17:45 ` Florian Weimer
2021-03-17 20:29 ` Ian Pilcher
@ 2021-03-17 20:47 ` Godmar Back
2021-03-17 21:03 ` Florian Weimer
1 sibling, 1 reply; 6+ messages in thread
From: Godmar Back @ 2021-03-17 20:47 UTC (permalink / raw)
To: Florian Weimer; +Cc: Ian Pilcher via Libc-help, Ian Pilcher
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug or not? printf allocates buffer & never frees it
2021-03-17 20:47 ` Godmar Back
@ 2021-03-17 21:03 ` Florian Weimer
0 siblings, 0 replies; 6+ messages in thread
From: Florian Weimer @ 2021-03-17 21:03 UTC (permalink / raw)
To: Godmar Back; +Cc: Ian Pilcher via Libc-help, Ian Pilcher
* 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-03-17 21:03 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-17 17:30 Bug or not? printf allocates buffer & never frees it Ian Pilcher
2021-03-17 17:45 ` Florian Weimer
2021-03-17 20:29 ` Ian Pilcher
2021-03-17 20:47 ` Godmar Back
2021-03-17 21:03 ` Florian Weimer
2021-03-17 19:23 ` Konstantin Kharlamov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).