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

Martin Sustrik sustrik at 250bpm.com
Wed Dec 8 16:27:00 CET 2010


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?

> On Windows, the leak was even worse, but I couldn't trace its source
> (no Valgrind for Windows unfortunately).
> Environment: Visual Studio 2010, 32-bit build, Windows 7 and Windows
> 2003 Server.

There was a leak there that was fixed in version 2.0.10. What version 
are you using?

The relevant commit is here:

https://github.com/zeromq/zeromq2/commit/6e9520533395b19ed6f6a17de6f196aa5e93da9f

> Proper thread pool that doesn't ever close threads fixed the problem
> for us both on Linux and Windows.

0MQ doesn't close its I/O threads either (until zmq_term is called).

Martin



More information about the zeromq-dev mailing list