https://bugs.kde.org/show_bug.cgi?id=421931
--- Comment #8 from Carlos O'Donell <car...@redhat.com> --- (In reply to Mark Wielaard from comment #7) > (In reply to Carlos O'Donell from comment #5) > > (In reply to Mark Wielaard from comment #3) > > > What is a "detached thread" according to you? There is no concept of > > > detached threads in valgrind, all threads are under control of valgrind > > > and > > > valgrind makes sure that only one (kernel) thread is scheduled to run at > > > any > > > one time. See > > > https://valgrind.org/docs/manual/manual-core.html#manual-core.pthreads > > > > If you use ptrace under the hood to stop a pthread detached thread, and > > therefore terminate it, then yes, there will be nothing else using the > > streams. > > > > If that's the case, and we feel comfortable with that as a position then I > > can flip this back to glibc and discuss *always* shutting down streams via > > __libc_freeres regardless of their state? > > We don't use ptrace under the hood, we control all kernel threads. From the > perspective of glibc valgrind provides the kernel interface. Valgrind core > doesn't use glibc itself. From the perspective of valgrind glibc is just > like any other code the process executes. With some exceptions, we intercept > some glibc functions, most specifically __libc_freeres. That function is > called after the process exits (from glibc's perspective). We should > probably make sure there are no other users of __libc_freeres, or if there > are, that they use it in the same way. So it seems a good idea to put this > back to glibc. There are other users of __libc_freeres(), particularly mtrace, which frees everything in a destructors, but that problably makes such code incompatible with valgrind and that's OK. Let me note, that even if we fix it in glibc, that is to say that we decree that all streams, buffered or unbuffered, are freed, there is going to be old glibc's and applications that use stderr (unbuffered) and allocate a buffer (possibly a 20 year old glibc bug) that is not freed. I leave it up to you to decide if you want to supress an unfreed stderr that will always show up when using stderr. I'll see about fixing it in glibc. -- You are receiving this mail because: You are watching all bug changes.
