* [Bug libc/26022] valgrind gives me error when fwprintf in stderr
2020-05-22 7:45 [Bug libc/26022] New: valgrind gives me error when fwprintf in stderr daffra.claudio at gmail dot com
@ 2020-05-22 20:07 ` carlos at redhat dot com
2020-05-29 19:40 ` mark at klomp dot org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: carlos at redhat dot com @ 2020-05-22 20:07 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=26022
Carlos O'Donell <carlos at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |carlos at redhat dot com
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
Freeing streams during application shutdown is difficult because detached
threads may be writing to unbuffered streams.
As such, stderr, and any other unbuffered streams are untouched during process
shutdown and are not freed by the resource freeing API that glibc exposes for
use by external allocation trackers.
That is to say that __libc_freeres() the public API which glibc uses to expose
resource freeing, will not free unbuffered streams to allow any last minute
writes.
Since stderr starts as unbuffered it is not freed. You can make stderr
buffered, and subject to freeing like this: setvbuf (stderr, NULL, _IOLBF, 0);
Valgrind should probably have a suppresion entry added for stderr because it's
a common stream to be used by applications.
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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libc/26022] valgrind gives me error when fwprintf in stderr
2020-05-22 7:45 [Bug libc/26022] New: valgrind gives me error when fwprintf in stderr daffra.claudio at gmail dot com
2020-05-22 20:07 ` [Bug libc/26022] " carlos at redhat dot com
@ 2020-05-29 19:40 ` mark at klomp dot org
2020-05-29 20:09 ` carlos at redhat dot com
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: mark at klomp dot org @ 2020-05-29 19:40 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=26022
Mark Wielaard <mark at klomp dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
CC| |mark at klomp dot org
Resolution|INVALID |---
Ever confirmed|0 |1
Last reconfirmed| |2020-05-29
--- Comment #2 from Mark Wielaard <mark at klomp dot org> ---
(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?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libc/26022] valgrind gives me error when fwprintf in stderr
2020-05-22 7:45 [Bug libc/26022] New: valgrind gives me error when fwprintf in stderr daffra.claudio at gmail dot com
2020-05-22 20:07 ` [Bug libc/26022] " carlos at redhat dot com
2020-05-29 19:40 ` mark at klomp dot org
@ 2020-05-29 20:09 ` carlos at redhat dot com
2020-06-04 9:45 ` daffra.claudio at gmail dot com
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: carlos at redhat dot com @ 2020-05-29 20:09 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libc/26022] valgrind gives me error when fwprintf in stderr
2020-05-22 7:45 [Bug libc/26022] New: valgrind gives me error when fwprintf in stderr daffra.claudio at gmail dot com
` (2 preceding siblings ...)
2020-05-29 20:09 ` carlos at redhat dot com
@ 2020-06-04 9:45 ` daffra.claudio at gmail dot com
2020-06-04 12:19 ` mark at klomp dot org
2020-06-04 16:58 ` daffra.claudio at gmail dot com
5 siblings, 0 replies; 7+ messages in thread
From: daffra.claudio at gmail dot com @ 2020-06-04 9:45 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=26022
--- Comment #4 from Claudio Daffra <daffra.claudio at gmail dot com> ---
file to reproduce valgrind error
#include <stdio.h>
#include <wchar.h>
int main ( void )
{
return 0 ;
}
error message
==1596== Memcheck, a memory error detector
==1596== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1596== Using Valgrind-3.16.0.GIT and LibVEX; rerun with -h for copyright
info
==1596== Command: ./prova
==1596==
==1596==
==1596== HEAP SUMMARY:
==1596== in use at exit: 13,697 bytes in 158 blocks
==1596== total heap usage: 172 allocs, 14 frees, 18,441 bytes allocated
==1596==
==1596== LEAK SUMMARY:
==1596== definitely lost: 0 bytes in 0 blocks
==1596== indirectly lost: 0 bytes in 0 blocks
==1596== possibly lost: 4,392 bytes in 5 blocks
==1596== still reachable: 9,305 bytes in 153 blocks
==1596== suppressed: 0 bytes in 0 blocks
==1596== Rerun with --leak-check=full to see details of leaked memory
==1596==
==1596== For lists of detected and suppressed errors, rerun with: -s
==1596== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
claudio@RastanX Documents %
compiler version
claudio@RastanX Documents % gcc -v
Configured with: --prefix=/Library/Developer/CommandLineTools/usr
--with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.3 (clang-1103.0.32.59)
Target: x86_64-apple-darwin19.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
s.o : macOS 10.15.5 (19F96)
with --leak-check=full valgrind gives me many other errors.
this occurs in macosx only,nothing to do with streams.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libc/26022] valgrind gives me error when fwprintf in stderr
2020-05-22 7:45 [Bug libc/26022] New: valgrind gives me error when fwprintf in stderr daffra.claudio at gmail dot com
` (3 preceding siblings ...)
2020-06-04 9:45 ` daffra.claudio at gmail dot com
@ 2020-06-04 12:19 ` mark at klomp dot org
2020-06-04 16:58 ` daffra.claudio at gmail dot com
5 siblings, 0 replies; 7+ messages in thread
From: mark at klomp dot org @ 2020-06-04 12:19 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=26022
--- Comment #5 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Claudio Daffra from comment #4)
>
> s.o : macOS 10.15.5 (19F96)
>
>
> with --leak-check=full valgrind gives me many other errors.
> this occurs in macosx only,nothing to do with streams.
I think the problem is that you are not using glibc on macosx. The libc
implementation you are using on macosx seems to have various bugs and/or leaks,
or might not support __libc_freeres to coordinate with valgrind. You might want
to report those issues to apple, assuming they provided the libc you are using
on macOS.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libc/26022] valgrind gives me error when fwprintf in stderr
2020-05-22 7:45 [Bug libc/26022] New: valgrind gives me error when fwprintf in stderr daffra.claudio at gmail dot com
` (4 preceding siblings ...)
2020-06-04 12:19 ` mark at klomp dot org
@ 2020-06-04 16:58 ` daffra.claudio at gmail dot com
5 siblings, 0 replies; 7+ messages in thread
From: daffra.claudio at gmail dot com @ 2020-06-04 16:58 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=26022
--- Comment #6 from Claudio Daffra <daffra.claudio at gmail dot com> ---
Ok i Will . Thank you .
Il gio 4 giu 2020, 14:19 mark at klomp dot org <
sourceware-bugzilla@sourceware.org> ha scritto:
> https://sourceware.org/bugzilla/show_bug.cgi?id=26022
>
> --- Comment #5 from Mark Wielaard <mark at klomp dot org> ---
> (In reply to Claudio Daffra from comment #4)
> >
> > s.o : macOS 10.15.5 (19F96)
> >
> >
> > with --leak-check=full valgrind gives me many other errors.
> > this occurs in macosx only,nothing to do with streams.
>
> I think the problem is that you are not using glibc on macosx. The libc
> implementation you are using on macosx seems to have various bugs and/or
> leaks,
> or might not support __libc_freeres to coordinate with valgrind. You might
> want
> to report those issues to apple, assuming they provided the libc you are
> using
> on macOS.
>
> --
> You are receiving this mail because:
> You reported the bug.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread