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

[Chris Lattner]

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

So now instead of calling a method on an object that is destroyed, this helpfully causes llvm_fatal_error() to be called.  This is progress (as noted when I committed this) but wasn't sufficient to fix rdar://8318441 or PR7043.

Since you've now reverted them, you've regressed both.  How exactly does 111321 not fix anything?

-Chris