[zeromq-dev] [2.1.0] Problems with lruqueue from The Guide (tm)

Steven McCoy steven.mccoy at miru.hk
Thu Dec 9 01:48:01 CET 2010


On 8 December 2010 23:27, Martin Sustrik <sustrik at 250bpm.com> wrote:

> Ivan,
>
> >   54 bytes in 1 blocks are possibly lost in loss record 581 of 1,126
> >      at 0x4006374: memalign (vg_replace_malloc.c:581)
> >      by 0x163188: ___tls_get_addr (in /lib/ld-2.3.4.so)
> >      by 0x6668340: ??? (in /lib/tls/libuuid.so.1.2)
> >      by 0x6668F55: uuid__generate_random (in /lib/tls/libuuid.so.1.2)
> >      by 0x6668FD8: uuid_generate_random (in /lib/tls/libuuid.so.1.2)
> >      by 0x6669005: uuid_generate (in /lib/tls/libuuid.so.1.2)
> >      by 0x659DD58: zmq::uuid_t::uuid_t() (uuid.cpp:86)
>
> This looks like a leak in uuid_generate. The documenation doesn't
> suggest that any memory has to be freed after the call:
>
> http://linux.die.net/man/3/uuid_generate
>
> Also, valgrind says "possibly lost". What does that mean exactly?


Clearly libuuid is using thread local storage, you can also see it in the
code,

https://www.google.com/codesearch/p?hl=en#ASP8zFzi3_w/uuid/gen_uuid.c&q=uuid__generate_random&l=535

However the possibly lost status is due to THREAD_LOCAL types being cleared
at thread shutdown, as discussed in this article:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3070.html

Presumably Valgrind as a hard time to catch thread atexit methods.

-- 
Steve-o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101209/a324fa70/attachment.htm>


More information about the zeromq-dev mailing list