... then, having realizing that it linked against the Ubuntu installed default version (libzmq3), I re-ran this against libzmq4 and the current libzmq 'trunk'. I get no races/issues in libzmq3 or libzmq4, but 4.1 definitely seems to have a problem, in that this test program is triggering GCC's stack smashing detector, so seems like a 4.1 specific issue mebe?
If I get some time tomorrow, I will try to figure out why (no obvious from a libzmq call in the backtrace). On Mon, Aug 18, 2014 at 9:53 PM, Thomas Rodgers <rodg...@twrodgers.com> wrote: > Hmmmm, I just ran this on my *nix box (Ubuntu 14.04, gcc4.8) with helgrind > and I get no races in zmq::msg_t::close() reported, nor do I see anything > in the implementation of zmq::msg_t::close() that's likely racey in > practice. > > > On Monday, August 18, 2014, Michi Henning <mi...@triodia.com> wrote: > >> Hi Thomas, >> >> thanks for the quick answer! >> >> > If the message size exceeds the 'vsm' message length limit, it becomes >> an 'lmsg'. This type is indeed heap allocated, and when the enclosing >> message type is copied, the copies share the reference to the underlying >> heap allocation (and any potential data races that come along with that). >> The lifetime is controlled by an atomic refcount. >> > zmq::msg_t::close() should not create a race as it relies on the >> atomic refcount dropping to zero before freeing the heap block. >> > >> > Access to the actual message data() could potentially create a data >> race, but the receiving side should never have access to a message that is >> still being written by a background thread. >> >> OK, so that sounds like the races on data() and memcpy() are bogus. What >> about the close() race though? I wasn't expecting to see that one. >> >> Cheers, >> >> Michi. >> _______________________________________________ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
