Memory leak in session_base.cpp:59

Description

When creating a socket, binding or connecting, a session object is created and never destroyed. It's trivially reproducible.

This is when doing a bind:

==28366== HEAP SUMMARY:
==28366== in use at exit: 552 bytes in 1 blocks
==28366== total heap usage: 76 allocs, 75 frees, 56,039 bytes allocated
==28366==
==28366== 552 bytes in 1 blocks are definitely lost in loss record 1 of 1
==28366== at 0x4C289A2: operator new(unsigned long, std::nothrow_t const&) (vg_replace_malloc.c:281)
==28366== by 0x5403D1C: zmq::session_base_t::create(zmq::io_thread_t*, bool, zmq::socket_base_t*, zmq::options_t const&, zmq::address_t const*) (session_base.cpp:59)
==28366== by 0x540A438: zmq::tcp_listener_t::in_event() (tcp_listener.cpp:103)
==28366== by 0x53F884D: zmq::epoll_t::loop() (epoll.cpp:161)
==28366== by 0x540AE45: thread_routine (thread.cpp:74)
==28366== by 0x5627EFB: start_thread (pthread_create.c:304)
==28366== by 0x512859C: clone (clone.S:112)

And this is when doing a connect:

==28400== HEAP SUMMARY:
==28400== in use at exit: 552 bytes in 1 blocks
==28400== total heap usage: 118 allocs, 117 frees, 60,645 bytes allocated
==28400==
==28400== 552 bytes in 1 blocks are definitely lost in loss record 1 of 1
==28400== at 0x4C289A2: operator new(unsigned long, std::nothrow_t const&) (vg_replace_malloc.c:281)
==28400== by 0x5403D1C: zmq::session_base_t::create(zmq::io_thread_t*, bool, zmq::socket_base_t*, zmq::options_t const&, zmq::address_t const*) (session_base.cpp:59)
==28400== by 0x5406DF6: zmq::socket_base_t::connect(char const*) (socket_base.cpp:480)
==28400== by 0x4E39939: zsocket_connect (zsocket.c:125)
==28400== by 0x4007EC: main (server.c:6)

Environment

None

Activity

Show:

Martin Hurton March 27, 2012 at 3:30 AM

Fixed in 00b4571bf1990e7c918ce6736c77757733848f5b.

PieterP March 18, 2012 at 7:30 PM

Test cases added to issues repository.

Fixed

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Priority

Created March 18, 2012 at 7:28 PM
Updated August 29, 2013 at 4:23 PM
Resolved March 27, 2012 at 3:30 AM