libzmq: Memory leak connecting a gazillion times to a pubsub

I am currently using a small suite of software that uses zeromq to distribute realtime data.

https://github.com/StichtingOpenGeo/universal/blob/master/universal-pubsub.c

After some data downtime, we noticed that the pubsub’s sucked up memory. Our clients typically reconnect every 60s if no data was received to overcome other network issues. I created a small test tool to figure out if there might be an issue with ZeroMQ.

https://github.com/StichtingOpenGeo/universal/blob/master/universal-sub-test.c

This shows up in ZeroMQ thus it makes me wonder: when should some destroys fly in?

==31474== 1,180,296 bytes in 1,521 blocks are possibly lost in loss record 45 of 47
==31474==    at 0x4C2A790: operator new(unsigned long, std::nothrow_t const&) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31474==    by 0x4E60B98: zmq::session_base_t::create(zmq::io_thread_t*, bool, zmq::socket_base_t*, zmq::options_t const&, zmq::address_t const*) (in /usr/lib64/libzmq.so.3.1.0)
==31474==    by 0x4E7042E: zmq::tcp_listener_t::in_event() (in /usr/lib64/libzmq.so.3.1.0)
==31474==    by 0x4E4EEED: zmq::epoll_t::loop() (in /usr/lib64/libzmq.so.3.1.0)
==31474==    by 0x4E70B89: thread_routine (in /usr/lib64/libzmq.so.3.1.0)
==31474==    by 0x588D313: start_thread (in /lib64/libpthread-2.20.so)
==31474==    by 0x517843C: clone (in /lib64/libc-2.20.so)

About this issue

  • Original URL
  • State: open
  • Created 10 years ago
  • Comments: 54 (19 by maintainers)

Most upvoted comments

On Apr 20, 2015 11:58 AM, “Stefan de Konink” notifications@github.com wrote:

Could this issue please get some priority?

With all respect, either provide a patch, or offer someone money to fix this, or wait until someone who has money / skills decides it’s a priority for them. Free software does not mean you can expect others to work on your issues unpaid.