Without interceptor implementation may call strlen on internal
buffers causing false msan errors.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
The new test FAILs on Solaris, and, I believe, rightly so:
For one, there's a warning:
` compiler-rt/test/sanitizer_common/TestCases/Posix/sem_open.cpp:14:38: warning: format specifies type 'int' but the argument has type 'pid_t' (aka 'long') [-Wformat] sprintf(name, "/sem_open_test_%d", getpid()); ~~ ^~~~~~~~ %ld
pid_t is int for 64-bit complations, but long for 32-bit ones. This can be fixed by printing as %ld and casting the getpid return value to
long to match.
Worse, however, the test execution FAILs:
Assertion failed: sem_close(s2) == 0, file /vol/llvm/src/llvm-project/local/compiler-rt/test/sanitizer_common/TestCases/Posix/sem_open.cpp, line 23
sem_close(s2) succeeds on Linux, but fails on Solaris with EINVAL. Looking closer, s1 and s2 are identical, as expected. On Solaris,
sem_close(s1) frees and deallocates the sem_t, so it has become invalid (unmapped even when looking with gdb) at the time sem_close(s2) is called.
Both Solaris sem_close(3C) and the corresponding XPG7 page state
The effect of subsequent use of the semaphore indicated by sem by this process is undefined.
so this behaviour seems perfectly valid.
There is also
If a process makes multiple successful calls to sem_open() with the same value for name, the same semaphore address is returned for each such successful call, provided that there have been no calls to sem_unlink(3C) for this semaphore.
Opening twice is not essential to the test, so I will remove it and fix type if sprintf.
bf6000dc98df82d9b493e0b5d247538f51d6b9ac
Opening twice is not essential to the test, so I will remove it and fix type if sprintf.
bf6000dc98df82d9b493e0b5d247538f51d6b9ac
Excellent, thanks.
clang-tidy: error: no template named 'AddrHashMap'; did you mean '__asan::AddrHashMap'? [clang-diagnostic-error]
not useful