[asan] Fix a deadlock halt_on_error-signals.c when `reporting_thread_tid_` is 0

[kubamracek]

Summary

On one of our bots, I'm seeing a deadlock in the halt_on_error-signals.c ASan test. I debugged the issue and it's a race condition when a signal is delivered after TryLock but before StartReporting in the following code:

explicit ScopedInErrorReport(ReportData *report = nullptr,
                           bool fatal = false) {
  halt_on_error_ = fatal || flags()->halt_on_error;

  if (lock_.TryLock()) {
    StartReporting(report);
    return;
  }
  ...
}

In this case, reporting_thread_tid_ is still 0, because it's never initialized to kInvalidTid, causing the nested call to ScopedInErrorReport to try to acquire the lock in lock_.Lock();. This issue can be reproduced by adding a SleepForMillis(100); call after TryLock but before StartReporting. The the test deadlocks every time.

Fixing this by statically initializing reporting_thread_tid_ to kInvalidTid.

[ygribov]

+1

[kubamracek]

so is this okay to land?

[kcc]

LGTM

compiler-rt/trunk/lib/asan/asan_report.cc

private:
   }
 
   static StaticSpinMutex lock_;
   static u32 reporting_thread_tid_;
   bool halt_on_error_;
 };
 
 StaticSpinMutex ScopedInErrorReport::lock_;
-u32 ScopedInErrorReport::reporting_thread_tid_;
+u32 ScopedInErrorReport::reporting_thread_tid_ = kInvalidTid;
 
 void ReportStackOverflow(const SignalContext &sig) {
   ScopedInErrorReport in_report(/*report*/ nullptr, /*fatal*/ true);
   Decorator d;
   Printf("%s", d.Warning());
   Report(
       "ERROR: AddressSanitizer: stack-overflow on address %p"
       " (pc %p bp %p sp %p T%d)\n",