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).



On Tue, Aug 19, 2014 at 2:03 AM, Michi Henning <mi...@triodia.com> wrote:

>
> On 19/08/14 13:28, Thomas Rodgers wrote:
>
>> ... 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).
>>
>
> Thanks heaps for that, I truly appreciate it!
>
> I'm running with version 4.0.4 here from the Utopic archives, with gcc 4.9.
>
> I've attached the output I'm getting from helgrind, just in case. I assume
> that yours will be pretty much identical. That was with a string length of
> 40. Note that I sometimes get a clean run, especially with shorter strings.
> I just tried with a length of 30 and, every now and then, helgrind reports
> zero errors (maybe one in ten tries).
>
> 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

Reply via email to