[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Call clearerr() on stdout before close_stream() is called.
From: |
David Cantrell |
Subject: |
Re: [PATCH] Call clearerr() on stdout before close_stream() is called. |
Date: |
Fri, 5 Feb 2016 06:31:41 -0500 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Thu, Feb 04, 2016 at 08:16:30AM -0700, Eric Blake wrote:
> On 02/04/2016 03:46 AM, David Cantrell wrote:
> > This is seen in bison and possibly other programs. Bison will
> > incorrectly receive SIGPIPE and terminate because close_stream() is
> > picking up a rogue EPIPE in errno. Before fclose(), clearerr(stdout)
> > needs to be called so that the errors it will check for are for the
> > immediate call of close_stream().
> > ---
> > lib/closeout.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/lib/closeout.c b/lib/closeout.c
> > index 311faf4..36895a2 100644
> > --- a/lib/closeout.c
> > +++ b/lib/closeout.c
> > @@ -106,6 +106,8 @@ close_stdout_set_ignore_EPIPE (bool ignore)
> > void
> > close_stdout (void)
> > {
> > + clearerr (stdout);
> > +
>
> This part is wrong. The whole point of close_stdout() is to detect any
> error that occurred in the stream prior to closing it, not just errors
> in closing the stream.
Ah, I gotcha. Makes more sense then. I am not very familiar with gnulib.
> > if (close_stream (stdout) != 0
> > && !(ignore_EPIPE && errno == EPIPE))
>
> But you are correct that if close_stream() does not set errno, then we
> may have a spurious EPIPE getting through to the second check. Under
> what conditions would close_stream() return non-zero but not set errno?
>
> I guess I need a bit more context to what bison is doing to why it
> thinks that clearing out any earlier fwrite() and similar failures prior
> to the close will prevent spurious EPIPE messages.
I can describe where I'm seeing it and then dig in to it to see what's going
on.
I am building webkitgtk. During the build of WebCore, there is a
CSSGrammar.y.in template that is preprocessed somehow, out pops
CSSGrammar.y, and then they run bison on that. Bison running on that file
exits with code 141. If I run bison directly from the shell, it still
happens. You get no error reporting or any kind of output from bison, it
just exits with code 141.
--
David Cantrell <address@hidden>
WH6DSN | http://blog.burdell.org/