I'm compiling compiler-rt via CMake+Ninja on x86_64+ArchLinux and one
of the tests fails on ToT:
MemorySanitizer :: chained_origin_with_signals.cc
The text expects uninitialized warnings while the execution prints
nothing, thus FileCheck fails.
Anyone seeing this?
is it still an issue?
Just by looking at the code, I don't see why it could fail. Do you
need any help debugging it?
Yes, it is. The problem here is that the program doesn't fail on my
box (release and debug builds), so I have no idea how to debug the
problem. According to the test, it's ran as "not
chained_origin_with_signals.cc.tmp", expecting it to fail. Also, the
FileCheck expects to find warnings on the output, for which there is
Maybe I'm missing some CMake flag or library, and that's why the
signal functionality is not working on my box?
Could it be that I'm misunderstanding signal semantics, and SIGUSR1 is
not guaranteed to be delivered (to the same process!) before kill()
returns? Could you check if that's what happens by adding a sleep()
You mean replacing SIGUSR1 with SIGHUP in the test case? Weird, I
don't see how they are different.
POSIX.1-2001 requires that if a process sends a signal to itself,
and the sending thread
does not have the signal blocked, and no other thread has it
unblocked or is waiting for it
in sigwait(3), at least one unblocked signal must be delivered
to the sending thread before
the kill() returns.
So, AFAIK, they should be identical. But I put some printfs and sleeps
around and it wasn't a synchronization issue. My man page says that
SIGUSR1 should terminate if there isn't a handler for it (different
than SIGINFO), but the process didn't terminate neither ran the
handlers, which is odd. SIGHUP didn't have that behaviour, and
executed the handler.
I'm not an expert in signals, so I can't comment on that part. But
given that this test is not about signals, but about the uninitialized
variable, I guess making it SIGHUP wouldn't hurt too much.
OK, we can switch to SIGHUP. Could you please verify that this SIGUSR1
behavior is not caused by MSan?
I can. I've removed every other compilation flags from clang and even
used GCC, with the exact same behaviour.