On 5/13/19 12:00 AM, Florian Weimer wrote:
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.
It might be fine for some of these environments, but surely it can't be
fine for others. If I'm relying on the startup routines to issue some
sort of report for any non-signalling exit, then calls to _exit will
bypass the report.
Look at the existing workaround
for sanitizers, and the comment in close_stream. The code is buggy
I agree the code is a hack. But it's not buggy: it's portable to any
environment that conforms to POSIX, and that's a wide variety of
environments. The problem seems to be that people want to run these
applications in debugging environments that don't conform to POSIX.
While I'm sympathetic to that goal, it's not a high-priority-enough
situation to call the current code "buggy".
A better fix here would not be to pile yet another hack into this hacky
module. It would be to write a better module (we could call it
"flushout", say) that would define a function ("flushout_stream", say)
that would act like fflush but would do a better job with NFS-based
streams by playing the dup+close+fsync trick. We could then modify
coreutils etc. to use this new module instead of the old one. The hard
part is the "modify coreutils etc." part, because flushout_stream will
be less convenient to use than the current API.
