[compiler-rt] [ASan] Prevent ASan/LSan deadlock by preloading modules before error reporting (PR #131756)
via llvm-commits
llvm-commits at lists.llvm.org
Wed Apr 16 23:26:23 PDT 2025
Camsyn wrote:
> #### **. Revert LSan Lock Order (Incomplete)**
> * **Approach**: Move LSan's acquisition of Lock B (thread lock) _before_ `dl_iterate_phdr` (Lock A). Historically, LSan acquired Lock B before `dl_iterate_phdr`, but commit [f1b6bd4](https://github.com/llvm/llvm-project/commit/f1b6bd403d52f41d0c55733387cf5f71753f3c25) moved it inside `dl_iterate_phdr` to handle potential `malloc` calls during iteration.
> * **Key Question**: Since ASan does not hold the allocator lock during error reporting, could reverting Lock B acquisition to pre-`dl_iterate_phdr` resolve the deadlock?
> * **Risk**: Thread creation within `dl_iterate_phdr` (now holding Lock B) might reintroduce deadlocks similar to those addressed in `f1b6bd4`.
Commit f1b6bd moved the alloca lock (as well as the thread lock) into `dl_iterate_phdr` to avoid deadlock with other threads performing alloc operations in `dl_iterate_phdr`.
As for moving out the thread lock, I have analyzed this fix schema; see the second point of the [above analysis](https://github.com/llvm/llvm-project/pull/131756#issuecomment-2771907374) for details :(. If LSan only advances the thread lock to `dl_iterate_phdr`, I am concerned that this will cause a new deadlock scenario (with another thread performing thread operations in the `dl_iterate_phdr`).
https://github.com/llvm/llvm-project/pull/131756
More information about the llvm-commits
mailing list