[zeromq-dev] libzmq and helgrind

Thomas Rodgers 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
> practice.
> 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.
>> Cheers,
>> Michi.
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140818/9546ab5f/attachment.html>

More information about the zeromq-dev mailing list