[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