bug-gnulib
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]