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

[Dan Gohman]

On Aug 17, 2010, at 4:34 PM, Chris Lattner wrote:

> 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?


The problematic condition appears to have been when errs() happens
to get destroyed before outs(), outs() happens to have a
non-empty buffer when it gets destroyed, and there's a write error
when outs() flushes its buffer. When this happens, report_fatal_error
tries to use a destroyed errs(), and badness ensues. r111320 fixes it.

111321 doesn't appear to fix anything, so I reverted it.

Dan