[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