Memory leak

[gtoonstra]

I'm just getting started with 0MQ and downloaded version "0MQ version 2.0.10 (Stable), released on 2010/10/15". That's compiled and installed on my system now.

Running the example "examples/C/wuserver.c", I'm getting a huge memory leak from the server, which causes my system to deplete all memory resources very quickly.

Running "valgrind --tool=memcheck --leak-check=full --show-reachable=yes" slows down the leak, but after half a minute or so, it shows:

==24242== 9,373,984 bytes in 914 blocks are possibly lost in loss record 29 of 29
==24242== at 0x4C2815C: malloc (vg_replace_malloc.c:236)
==24242== by 0x4E52A89: zmq::writer_t::write(zmq_msg_t_) (yqueue.hpp:107)
==24242== by 0x4E54696: zmq::pub_t::write(zmq::writer_t_, zmq_msg_t_) (pub.cpp:162)
==24242== by 0x4E54801: zmq::pub_t::xsend(zmq_msg_t_, int) (pub.cpp:110)
==24242== by 0x4E5805D: zmq::socket_base_t::send(zmq_msg_t*, int) (socket_base.cpp:443)
==24242== by 0x400EC5: s_send (in /home/gt/temp/zmq/server)
==24242== by 0x4013A6: main (in /home/gt/temp/zmq/server)

So it appears that memory malloc'd in yqueue.hpp doesn't get cleaned up. This may be an issue with the tutorial or the code itself, but judging from the way how an entry is added to a list of some sorts, it's probably the code. Offending line:

end_chunk->next = (chunk_t*) malloc (sizeof (chunk_t));

Thanks for looking into this!

[sustrik]

Looking at weserver.c I notice there's an infinite loop. How come valgrind shows leaks if the program doesn't terminate?

[gtoonstra]

I pressed Ctrl-C, because the PC started to become unresponsive. 4GB of memory used after 1 minute running time. My quick assumption was therefore that there was a memory leak, but I realize that maybe this is per the design, to allow application/service developers to develop any throttling strategies themselves. I've inserted a simple usleep( 1000 ) in there, sleeping for 1ms and memory is totally stable now, so it's due to the huge amount of messages that the server attempts to push out, I think.

[sustrik]

Yes. It happens when sender sends messages faster than receiver receives them. Messages are the queued until ultimately all the memory is spent. To prevent it you can set ZMQ_HWM option to limit the size of the queue. Closing the issues.