[Bug libc/26022] valgrind gives me error when fwprintf in stderr

["carlos at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=26022

--- Comment #3 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Mark Wielaard from comment #2)
> (In reply to Carlos O'Donell from comment #1)
> > I've filed a Valgrind bug here:
> > https://bugs.kde.org/show_bug.cgi?id=421931
> > 
> > Please feel free to follow up there if you think it needs an update or you
> > want to give a +1 regarding your use case.
> > 
> > I'm marking this RESOLVED/INVALID for glibc.
> 
> As discussed in that bug, lets reconsider if this is something that can be
> cleaned up or clarified in glibc. valgrind itself doesn't use streams, or
> even link against glibc itself. When valgrind "calls" __libc_freeres the
> user process as already exitted, no other code/threads that could call into
> glibc will run during or after the call to __libc_freeres. Are there any
> other users of __libc_freeres that might not make those guarantees?

The problem is that valgrind is unique. No other library that uses
__libc_freeres, including glibc's own mtrace, goes to as much lengths as
valgrind does to get out of the way of the runtime. It is expected that
__libc_freeres can be called from a destructor, and so we may have threads
still writing to unbuffered streams, and we don't want to free those streams if
they have internal data (there might be a distinct bug there). Therefore
valgrind users whose application touches stderr may always see a leak in
stderr, and it's up to valgrind to supress that or not.

In the meantime I'm going to try track down why stderr, unbuffered as it is,
allocates anything, which we think might actually be a bug. Even if we fix the
bug, valgrind is left with many old glibcs before the new glibc makes it out
into production.

-- 
You are receiving this mail because:
You are on the CC list for the bug.