TSAN reports a sporadic data race in the zeromq calls of the AZMQ binding:
It seems to have to do something with a pointer written/read by epol_ctl zmq::epoll_t::add_fd
Please see output below for more details.
The question is, whether this is a false positive reported by gcc's thread sanitizer or if this is an actual data race in libzmq/azmq
Environment
libzmq version (commit hash if unreleased): 4.8.1
libazmq version (commit hash if unreleased): 1.0.3
OS: 22.04.1-Ubuntu
Compiler: g++ v11.3.0
Minimal test code / Steps to reproduce the issue
The data race is not always reported by TSAN, it is more sporadically occurring, i.e. the execution of
the example needs to be triggered several times to see TSAN reporting the issue.
Issue description
TSAN reports a sporadic data race in the zeromq calls of the AZMQ binding:
It seems to have to do something with a pointer written/read by
epol_ctl zmq::epoll_t::add_fd
Please see output below for more details.The question is, whether this is a false positive reported by gcc's thread sanitizer or if this is an actual data race in libzmq/azmq
Environment
Minimal test code / Steps to reproduce the issue
The data race is not always reported by TSAN, it is more sporadically occurring, i.e. the execution of the example needs to be triggered several times to see TSAN reporting the issue.
What's the actual result? (include assertion message & call stack if applicable)
What's the expected result?
No data race.