* Paul Eggert: >> As long as you link libraries dynamically, any of the directly or indirectly >> linked libraries can introduce an ELF destructor or atexit() handler anytime, > > I don't see any way around this problem in general with the closeout > module's current API, because when it discovers an I/O error it calls > _exit, and _exit also clashes with that kind of cleanup handling.
This isn't the problem. fflush may also realistically cause SIGPIPE to be delivered to the process. That's all fine. The relevant case is where there is no error, and we do not call _exit. I'm worried that the current implementation introduces a use-after-free bug under certain, quite reasonable circumstances. All that is needed is a shared object that tries to log something to stderr from an ELF destructor. I don't think that's something that can be ruled out, or can be assumed to happen in development environments only. Even if I didn't have a user bug report about this issue, I would have expected the current behavior to be unacceptable from a quality-of-implementation perspective. Look at the existing workaround for sanitizers, and the comment in close_stream. The code is buggy and needs to be fixed. My offer to write patch along the lines that Neil Brown sketched still stands, but so does my concern that polishing it will require more work than the patch itself. Thanks, Florian
