Hi Bill, indeed I've found ThreadSanitizer to be more effective i.e., it contains much less false positives compared to Helgrind... still I'm getting several race condition warnings out of libzmq 4.2.3... indeed I actually built only my application code with -fsanitize=thread... do you know if I need to rebuild libzmq with that option as well? I will try to see if it makes any difference!
Thanks, Francesco 2018-02-24 15:17 GMT+01:00 Bill Torpey <[email protected]>: > I’m using clang’s Thread Sanitizer for a similar purpose, and just > happened to notice that the TSAN docs use ZeroMQ as one of the example > suppressions: https://github.com/google/sanitizers/wiki/ > ThreadSanitizerSuppressions > > I assume that the reason for suppressing libzmq.so has to do with (legacy) > sockets not being thread-safe, so the code may exhibit race conditions that > are irrelevant given that the code is not intended to be called from > multiple threads. > > FWIW, you may want to check out the clang sanitizers — they have certain > advantages over valgrind — (faster, multi-threaded, etc.) if you are able > to instrument the code at build time. > > > On Feb 23, 2018, at 6:52 AM, Luca Boccassi <[email protected]> > wrote: > > On Fri, 2018-02-23 at 12:22 +0100, Francesco wrote: > > Hi all, > I'm trying to further debug the problem I described in my earlier > mail ( > https://lists.zeromq.org/pipermail/zeromq-dev/2018-February/032303.ht > ml) so > I decided to use Helgrind to find race conditions in my code. > > My problem is that apparently Helgrind 3.12.0 is reporting race > conditions > against zmq::atomic_ptr_t<> implementation. > Now I know that Helgrind has troubles with C++11 atomics but by > looking at > the code I see that ZMQ is not using them (note: I do have > ZMQ_ATOMIC_PTR_CXX11 defined but I also have ZMQ_ATOMIC_PTR_INTRINSIC > defined, so the latter wins!). > > In particular Helgrind 3.12.0 tells me that: > > > ==00:00:00:11.885 29399== > ==00:00:00:11.885 29399== *Possible data race during read of size 8 > at > 0xB373BF0 by thread #4* > ==00:00:00:11.885 29399== Locks held: none > ==00:00:00:11.885 29399== at 0x6BD79AB: > *zmq::atomic_ptr_t<zmq::command_t>::cas*(zmq::command_t*, > zmq::command_t*) > (atomic_ptr.hpp:150) > ==00:00:00:11.885 29399== by 0x6BD7874: > zmq::ypipe_t<zmq::command_t, > 16>::check_read() (ypipe.hpp:147) > ==00:00:00:11.885 29399== by 0x6BD7288: > zmq::ypipe_t<zmq::command_t, > 16>::read(zmq::command_t*) (ypipe.hpp:165) > ==00:00:00:11.885 29399== by 0x6BD6FE7: > zmq::mailbox_t::recv(zmq::command_t*, int) (mailbox.cpp:98) > ==00:00:00:11.885 29399== by 0x6BD29FC: > zmq::io_thread_t::in_event() > (io_thread.cpp:81) > ==00:00:00:11.885 29399== by 0x6BD05C1: zmq::epoll_t::loop() > (epoll.cpp:188) > ==00:00:00:11.885 29399== by 0x6BD06C3: > zmq::epoll_t::worker_routine(void*) (epoll.cpp:203) > ==00:00:00:11.885 29399== by 0x6C18BA5: thread_routine > (thread.cpp:109) > ==00:00:00:11.885 29399== by 0x4C2F837: mythread_wrapper > (hg_intercepts.c:389) > ==00:00:00:11.885 29399== by 0x6E72463: start_thread > (pthread_create.c:334) > ==00:00:00:11.885 29399== by 0x92F901C: clone (clone.S:109) > ==00:00:00:11.885 29399== > ==00:00:00:11.885 29399== This conflicts with a previous write of > size 8 by > thread #2 > ==00:00:00:11.885 29399== Locks held: 1, at address 0xB373C08 > ==00:00:00:11.885 29399== at 0x6BD77F4: > *zmq::atomic_ptr_t<zmq::command_t>::set*(zmq::command_t*) > (atomic_ptr.hpp:90) > ==00:00:00:11.885 29399== by 0x6BD7422: > zmq::ypipe_t<zmq::command_t, > 16>::flush() (ypipe.hpp:125) > ==00:00:00:11.885 29399== by 0x6BD6DF5: > zmq::mailbox_t::send(zmq::command_t const&) (mailbox.cpp:63) > ==00:00:00:11.885 29399== by 0x6BB9128: > zmq::ctx_t::send_command(unsigned int, zmq::command_t const&) > (ctx.cpp:438) > ==00:00:00:11.885 29399== by 0x6BE34CE: > zmq::object_t::send_command(zmq::command_t&) (object.cpp:474) > ==00:00:00:11.885 29399== by 0x6BE26F8: > zmq::object_t::send_plug(zmq::own_t*, bool) (object.cpp:220) > ==00:00:00:11.885 29399== by 0x6BE68E2: > zmq::own_t::launch_child(zmq::own_t*) (own.cpp:87) > ==00:00:00:11.885 29399== by 0x6C03D6C: > zmq::socket_base_t::add_endpoint(char const*, zmq::own_t*, > zmq::pipe_t*) > (socket_base.cpp:1006) > ==00:00:00:11.885 29399== Address 0xb373bf0 is 128 bytes inside a > block of > size 224 alloc'd > ==00:00:00:11.885 29399== at 0x4C2A6FD: operator new(unsigned > long, > std::nothrow_t const&) (vg_replace_malloc.c:376) > ==00:00:00:11.885 29399== by 0x6BB8B8D: > zmq::ctx_t::create_socket(int) > (ctx.cpp:351) > ==00:00:00:11.885 29399== by 0x6C284D5: zmq_socket (zmq.cpp:267) > ==00:00:00:11.885 29399== by 0x6143809: > ZmqClientSocket::Config(PubSubSocketConfig const&) > (ZmqRequestReply.cpp:303) > ==00:00:00:11.885 29399== by 0x6144069: > ZmqClientMultiSocket::Config(PubSubSocketConfig const&) > (ZmqRequestReply.cpp:407) > ==00:00:00:11.885 29399== by 0x61684EF: client_thread_main(void*) > (ZmqRequestReplyUnitTests.cpp:132) > ==00:00:00:11.886 29399== by 0x4C2F837: mythread_wrapper > (hg_intercepts.c:389) > ==00:00:00:11.886 29399== by 0x6E72463: start_thread > (pthread_create.c:334) > ==00:00:00:11.886 29399== by 0x92F901C: clone (clone.S:109) > ==00:00:00:11.886 29399== Block was alloc'd by thread #2 > > > Is this a known (and ignorable) issue with zmq::atomic_ptr_t<>? > > Thanks, > Francesco > > > Yeah I started trying to put together a suppression file but never > finished it: > > https://github.com/bluca/libzmq/commit/fb9ee9da7631f9506cbfcd6db29a28 > 4ae6e9651e > > Hope to have time to finish working on it eventually (feel free to > contribute!) as it's very noisy right now, as it can't know about our > lock-free queue implementation without the custom suppression file > > -- > Kind regards, > Luca Boccassi_______________________________________________ > zeromq-dev mailing list > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
