[compiler-rt] [rtsan] Fix issue when intercepted function was not execve in test (PR #144018)
via llvm-commits
llvm-commits at lists.llvm.org
Thu Jun 12 22:04:44 PDT 2025
llvmbot wrote:
<!--LLVM PR SUMMARY COMMENT-->
@llvm/pr-subscribers-compiler-rt-sanitizer
Author: Chris Apple (cjappl)
<details>
<summary>Changes</summary>
On my mac, this started having `os_unfair_lock_lock` as the intercepted function.
I dropped the name so any second intercepted call will pass the test.
---
Full diff: https://github.com/llvm/llvm-project/pull/144018.diff
1 Files Affected:
- (modified) compiler-rt/test/rtsan/fork_exec.cpp (+6-1)
``````````diff
diff --git a/compiler-rt/test/rtsan/fork_exec.cpp b/compiler-rt/test/rtsan/fork_exec.cpp
index 3b2d2e5ca2f5d..5890a0936a2f7 100644
--- a/compiler-rt/test/rtsan/fork_exec.cpp
+++ b/compiler-rt/test/rtsan/fork_exec.cpp
@@ -45,7 +45,12 @@ int main() MAYBE_NONBLOCKING {
}
// CHECK-NOHALT: Intercepted call to {{.*}} `fork` {{.*}}
-// CHECK-NOHALT: Intercepted call to {{.*}} `execve` {{.*}}
+
+// We should also get some other intercepted call. On some systems this
+// is `execve`, on others, it's a lock to set up `execve`. In either
+// case, just check that we get a second intercepted call, don't sweat
+// the name.
+// CHECK-NOHALT: Intercepted call to {{.*}}
// usleep checks that rtsan is still enabled in the parent process
// See note in our interceptors file for why we don't look for `wait`
``````````
</details>
https://github.com/llvm/llvm-project/pull/144018
More information about the llvm-commits
mailing list