[Bug libc/13983] __libc_message() shouldn't blindly write to STDERR_FILENO

["bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=13983

--- Comment #17 from Rich Felker <bugdal at aerifal dot cx> 2012-04-16 17:21:32 UTC ---
Hey, I didn't mean to stir up such reactions... I agree it's bad for glibc to
make these writes. My point was that it's a quality of implementation issue
rather than a conformance issue. My preference (and action in musl, since you
brought it up) is never to write debugging messages at all, and simply crash as
soon as possible when memory corruption has been detected; this is also the
most secure route since it avoids making any further function calls (which, if
the GOT/PLT was corrupted, could be unsafe). I'll admit it's also the least
informative, as it requires core files or running under a debugger to discover
what happened.

With that said, glibc has chosen the approach of being verbose and attempting
to report some forms of UB to the user through messages. Originally (based on
the non-working isatty approach) I thought it prohibitively difficult to avoid
the situation, but since there's now a clean and working patch for the issue, I
withdraw my claim that the bug report is invalid. I think the fallback syslog
path could use some auditing though. Unless it's extremely simple, it could
cause programs in a corrupt state to hang (deadlock issues) or worse; just
losing the debug output in this case may be the lesser of two evils.

I still maintain that an application which calls fclose(stderr) is broken, and
if it's doing anything nontrivial, probably nonportable. For example, if it
calls a library which happens to try to write something to stderr, and stderr
has been closed, the result is undefined behavior. It may work on many
implementations, but it's a bad idea. It may be nice for glibc's documentation
to recommend alternatives to fclose for the standard streams (for instance,
freopen or dup2 with /dev/null, though freopen has some of its own pitalls).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.