[zeromq-dev] libzmq and helgrind
rodgert at twrodgers.com
Tue Aug 19 05:28:05 CEST 2014
... 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 <rodgert at twrodgers.com>
> 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
> On Monday, August 18, 2014, Michi Henning <michi at 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.
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev