On 20 Aug 2014, at 1:24 , Thomas Rodgers <rodg...@twrodgers.com> wrote:
> Ignore the 4.1 stack smashing issue, that was a brain fart on my part... > > I ran this (again Ubuntu 14.04 gcc4.8), and this time actually changed the > len > 29 bytes (sorry it was late, I had the stupid), got the msg_t::close() > race reported by helgrind. > > I think these are bogus reports, there is a lock free queue implementation, > ypipe_t (uses CAS, which if it were truly broken, would have reared it's head > well before now) that sits between the context's thread (which is running the > decoder, where the msg_t::init_size() call happens) and your receiving > thread (where msg_t::close() happens). The queue imposes a strict 'happens > before' relationship, the receiving side will not call close before the > decoder has fully placed the message on the pipe (it does this by shallow > copy, then calls msg_t::init() to reset it's local copy before handling the > next message). Hi Thomas, thanks for taking the time to look at this, I'm much obliged! I'll add the relevant suppression to my list. I'll keep nibbling away at this as I can find the time. I suspect that what I come up with will be incomplete, but it'll at least be a start. I think it would be awesome to have a solid helgrind suppression file for zmq in the distribution. I'm sure I'm not the only one who would appreciate it. I'll be happy to contribute what I can come up with but, as I said, I'm afraid it'll be incomplete because I'm using only a subset of zmq. Cheers, Michi. _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
