bug-gnulib
[Top][All Lists]
Advanced

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



reply via email to

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