[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: undefined behavior in closeout, aggravated by libsigsegv
From: |
Jim Meyering |
Subject: |
Re: undefined behavior in closeout, aggravated by libsigsegv |
Date: |
Sat, 18 Jul 2009 14:48:30 +0200 |
Eric Blake wrote:
> According to Jim Meyering on 7/18/2009 2:42 AM:
>> How about fixing gnulib's lib/error.c to do the right thing?
>> Then if you teach m4/error.m4 to detect when glibc's error function
>> is defective (currently always) it can use the improved replacement.
>
> It is not defective on Linux (that is, glibc's fflush behaves reliably
> even after fclose(stdout), and glibc can exploit this fact in its error()
> implementation). And according to doc/glibc-functions/error.texi, no
> other platforms provide error(), so we already provide it everywhere else.
> Since the gnulib error module already has changes not currently in glibc,
> we can go ahead and change error() without worrying about glibc adopting
> it (although with #if _LIBC guards to make upstream adoption easier).
>
> How about this patch? It was enough to fix the behavior of m4 on cygwin
I have a slight preference for omitting the #if !_LIBC guards,
and thus adopting the improvement unconditionally whenever error.c is used.
The added fcntl call has minimal cost (at least that's my recollection
from back when I measured it), and in the unusual case of already-closed
stdout, there will be no failing close syscall to distract readers of
strace output logs.
But either way is fine.
Thanks for working on this.
...
> +2009-07-18 Eric Blake <address@hidden>
> +
> + error: avoid undefined use of stdout
> + * lib/error.c (error, error_at_line): Check that fd 1 is open
> + before flushing stdout. Avoids a crash on cygwin when libsigsegv
> + is handling faults and the close_stdout module wants to report the
> + detection of closed stdout as an error.