From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 414EA39874D5; Fri, 29 May 2020 20:09:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 414EA39874D5 From: "carlos at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/26022] valgrind gives me error when fwprintf in stderr Date: Fri, 29 May 2020 20:09:52 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.27 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: carlos at redhat dot com X-Bugzilla-Status: REOPENED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 20:09:53 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26022 --- Comment #3 from Carlos O'Donell --- (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=3D421931 > >=20 > > 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. > >=20 > > I'm marking this RESOLVED/INVALID for glibc. >=20 > 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 in= to > 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 stream= s 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. --=20 You are receiving this mail because: You are on the CC list for the bug.=