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. On Sun, Aug 17, 2014 at 8:28 PM, Michi Henning <mi...@triodia.com> wrote: > Hi, > > I'm trying to put together a helgrind suppression file for use with zmq > programs. There is lots of noise coming from helgrind without suppressions > due to the lock-free stuff going on in zmq. > > I have a bunch of suppressions at the moment that get rid of some or the > more common errors. While I was working on this, I came across a few that > are puzzling, and I'm looking for advice whether these are false positives > or real. I've attached a trivial program that communicates between two > threads with REQ/REP, each thread using its own context. > > The server thread just echoes back what it receives, and the client thread > checks that what it received matches what it sent. > > This program works with zero errors when I run it with the attached > suppression file: > > $ valgrind --tool=helgrind --suppressions=suppress ./a.out > ... > ==4671== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 790 from 483) > > The client thread sends a string of 29 bytes: > > const int len = 29; // Noise happens if len >= 30 > const std::string payload(len, 'a'); > ... > zmq::message_t request(payload.size()); > memcpy((void *)request.data(), payload.c_str(), payload.size()); > socket.send(request); > > Now, as soon as the length of the string is 30 bytes or more, I get a > large number of potential races reported by helgrind. It looks like the > string contents spill over onto the heap at that point, so the zmq code > takes a different path. > > I'm seeing races in zmq::msg_t::data() and memcpy(), as well as a race in > zmq::msg_t::close(). > > My question is whether these are false positives or not. I'd much > appreciate any input you might have. (I'm not familiar with the zmq code > base, so I'm hoping that someone who knows the code might be able to help.) > > I've attached the program and the suppression file I used. > > Compile with (gcc 4.9): > > c++ -g -std=c++11 main.cpp -lzmq -lpthread > > and run as above. > > Thanks, > > 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
