Re: undefined behavior in closeout, aggravated by libsigsegv

[Bruno Haible]

Hi Eric,

> I've traced it to the fact that m4 uses the closeout module, which does the 
> following:
> 
> calls close_stream (stdout)
> => fclose (stdout)
> detects that pending data was lost, so call error()
> => fflush (stdout)
> 
> According to POSIX, using stdout after it has been passed to fclose is 
> undefined behavior.

Yup. We did not detect this bug earlier because on most systems, fflush
returns -1/EBADF in this situation, rather than crashing.

> What's the best way to do that?  Have 
> close_stdout call freopen("/dev/null","w",stdout) prior to calling error()?

Yes, this looks like the right fix to me. With "/dev/null" being replaced with
DEV_NULL defined as in lib/pipe.h, for mingw portability.

> Convince the glibc folks to change error() to not call fflush(stdout) if 
> fileno
> (stdout) is closed?

This would not help: After fclose (stdout), "any use of stdout results in
undefined behavior", says POSIX, hence fileno (stdout) is already undefined
behaviour.

> Rewrite close_stdout to open-code the error-printing  
> actions instead of calling error()?

That would go against the goal of consistent error reporting. Some tools
(like emacs) analyze the error output of a program and rely on the expected
formatting of error messages.

> there is currently a 
> thread on the cygwin list about a crash under Windows 2008 R2 64-bit, where 
> Windows has tightened the rules on what forms a valid SEH exception chain and 
> the cygwin handler was violating those rules; and that thread has also raised 
> the concern that libsigsegv may be making the same mistakes by trying to 
> override cygwin's handler:
> 
> http://cygwin.com/ml/cygwin/2009-07/msg00630.html
> http://cygwin.com/ml/cygwin/2009-07/msg00635.html

The mail at http://cygwin.com/ml/cygwin/2009-07/msg00607.html indicates that
the problem was with incorrect nesting of SEH exception chain 
additions/removals.
The values of the addresses in that chain appear to be irrelevant. Thus it
does not matter whether libsigsegv is compiled as a DLL or statically. At least
that's what I understand from the thread.

Bruno