Issue 138311
Summary RTSan unit-tests can crash due to use of hard-coded file descirptors
Labels new issue, compiler-rt:rtsan
Assignees
Reporter jmorse
    Hi -- we (Sony) occasionally see crashes coming out of the RTSan unit tests. The root cause boils down to some of the file-descriptors being passed into syscalls actually being legitimate data under some circumstances. In combination with llvm-lit using GoogleTest sharding, different unit tests are interleaved and we see emergent effects, such as this sequence:
 *  CloseDiesWhenRealtime [0] closes file descriptor zero -- which is a legitimate file description, it's stdin on posix hosts,
 * OpeningASocketDiesWhenRealtime [1] creates a socket, which comes back as file descriptor zero,
 * SendToASocketDiesWhenRealtime [2] writes nothingness to file descriptor zero, and the process crashes with SIGPIPE because fd zero is a socket and not connected to anything. It would otherwise receive a EBADF return code.

These crashes have come and go; currently they're gone because GoogleTest sharding doesn't string together the sequence above, but it might do as more tests are added to the file. I feel to improve test robustness, it would be much safer if all syscalls used a constant illegal file descriptor instead of hardcoding zero. It's also worth noting that the `kNotASocketFd` is zero, a legitimate file descriptor, where it should probably be `-1`.

[0] https://github.com/llvm/llvm-project/blob/7cc4472037b43971bd3ee373fe75b5043f5abca9/compiler-rt/lib/rtsan/tests/rtsan_test_interceptors_posix.cpp#L453
[1] https://github.com/llvm/llvm-project/blob/7cc4472037b43971bd3ee373fe75b5043f5abca9/compiler-rt/lib/rtsan/tests/rtsan_test_interceptors_posix.cpp#L1345C29-L1345C59
[2] https://github.com/llvm/llvm-project/blob/7cc4472037b43971bd3ee373fe75b5043f5abca9/compiler-rt/lib/rtsan/tests/rtsan_test_interceptors_posix.cpp#L1351C29-L1351C58
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to