[llvm-commits] [llvm] r111321 - /llvm/trunk/lib/Support/raw_ostream.cpp

Chris Lattner clattner at apple.com
Tue Aug 17 16:34:22 PDT 2010


On Aug 17, 2010, at 4:31 PM, Dan Gohman wrote:
On Aug 17, 2010, at 4:11 PM, Chris Lattner wrote:
>> Author: lattner
>> Date: Tue Aug 17 18:11:56 2010
>> New Revision: 111321
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=111321&view=rev
>> Log:
>> Fix the rest of rdar://8318441 which happens when a raw_fd_ostream
>> (e.g. errs()) fails in close() due to (e.g.) a broken pipe.  As
>> previously written, the had_error() flag would get set and then
>> the raw_ostream dtor would report a fatal error.  There is nothing
>> the client can do about this and we have no way to report the error,
>> so just eat it.
> 
> For errs(), ShouldClose is set to false, so this problem shouldn't
> be possible.
> 
> For raw_fd_ostream in general, it's not safe to ignore close(2)
> errors, especially since raw_fd_ostream doesn't use fsync. There is
> in fact something the client can do: it can call close() on the
> raw_fd_ostream, and then check for errors.

In practice, we're getting mysterious spurious failures in clang with stack traces like this:

                3 clang:  llvm::report_fatal_error + 69
                  3 clang:  llvm::report_fatal_error + 40
                    3 clang:  llvm::raw_fd_ostream::~raw_fd_ostream + 229
                      3 libSystem.B.dylib:  __cxa_finalize + 274
                        3 libSystem.B.dylib:  exit + 18
                          3 clang:  start + 59

Since the only streams that are globals that I'm aware of are errs() and outs(), this sounds to me like an error closing these streams.  What do you suggest we do?

-Chris



More information about the llvm-commits mailing list