[compiler-rt] [asan][test] Fix flake in asan_lsan_deadlock test (PR #141145)

[Kunqiu Chen via llvm-commits]

Camsyn wrote:

@ilovepi 
> Is your reasoning about SUMMARY reporting being a reliable signal correct?

If all went well, then "SUMMARY" should have been printed after <STACK TRACE>, which is the expected behavior of ASan's reporting. 

However,  your CI report does not even have < STRACE TRACE> in. I think this just means that the deadlock was triggered by the test case and was killed by the `WatchDog` thread when reaching its timeout threshold--60s.


> How do you ensure lock acquisitions overlap?

As mentioned in PR h#131756, we cannot finely control lock acquisition order under ASan (`__asan::ScopedInErrorReport`) and LSan (`__lsan::__lsan_do_leak_check`).
Therefore, as a test case outside of LSan and Asan, I can only make the critical sections of ASan(`__asan :: ScopedInErrorReport`) and LSan (`__lsan :: __lsan_do_leak_check`)  are reached at roughly the same time, expecting to trigger deadlocks contained in `__lsan :: __lsan_do_leak_check` (A - > B) and `__asan :: ScopedInErrorReport` (B- > A) with a high probability. 

Yes, even without the relevant fix, the test case does not reliably reproduce the deadlock (but when running on an idle system, it is **NEARLY** stable to trigger the bug). Anyway, for your instance, if the new spawn thread ends early before we enter `__lsan_do_leak_check`, it will only pass the test harmlessly as it should output "Summary:".

---

Overall, I think this test case clearly exposes the true deadlock flaw of ASan/LSan, and am not sure if it should be disabled.

https://github.com/llvm/llvm-project/pull/141145