Please use this template for reporting suspected bugs or requests for help.
Issue description
The memory allocated by zmq::msg_t::init_size is not called by the svr-node. In certain scenarios, memory is not released, resulting in memory leakage of the svr-node
Environment
libzmq version (commit hash if unreleased): zmq4.0.3 czmq2.2.0
OS: centos7
Minimal test code / Steps to reproduce the issue
(1) Run the pmap -x 'pidof svr-node' command to view the map information of the process, denoted as a.txt
(2) Grab the address assigned by malloc and call stack through systemtap
(3) After some time. Run the pmax -x 'pidof scr-node' command again to view the maps of the process, denoted as b.txt
(4) Compare a.xt and b.xt to find out the interval of memory change (it can be considered as the leaked memory address, and this idea is also verified by dumping out the memory through gdb).
(5), by systemtap print malloc address and the call stack, found [/ dom/storoswd iraid/lib/libzmq. So the 3.1.0 + 0 x19fb1/0 x250000] than the suspicious (this position memory allocated on interval, This address corresponds to the init_size function)
(6) Set conditional breakpoints by gdb in zmq::msg_t::init_size and zmq::msg_t::close () functions respectively, and debug online; And record the number of breakpoints hit.
(7) By analyzing the number of breakpoints entering, it is found that the number of times entering init_size is more than that of close; And that gap has grown over time.
What's the actual result? (include assertion message & call stack if applicable)
Please use this template for reporting suspected bugs or requests for help.
Issue description
The memory allocated by zmq::msg_t::init_size is not called by the svr-node. In certain scenarios, memory is not released, resulting in memory leakage of the svr-node
Environment
Minimal test code / Steps to reproduce the issue
(1) Run the pmap -x 'pidof svr-node' command to view the map information of the process, denoted as a.txt (2) Grab the address assigned by malloc and call stack through systemtap (3) After some time. Run the pmax -x 'pidof scr-node' command again to view the maps of the process, denoted as b.txt (4) Compare a.xt and b.xt to find out the interval of memory change (it can be considered as the leaked memory address, and this idea is also verified by dumping out the memory through gdb). (5), by systemtap print malloc address and the call stack, found [/ dom/storoswd iraid/lib/libzmq. So the 3.1.0 + 0 x19fb1/0 x250000] than the suspicious (this position memory allocated on interval, This address corresponds to the init_size function) (6) Set conditional breakpoints by gdb in zmq::msg_t::init_size and zmq::msg_t::close () functions respectively, and debug online; And record the number of breakpoints hit. (7) By analyzing the number of breakpoints entering, it is found that the number of times entering init_size is more than that of close; And that gap has grown over time.
What's the actual result? (include assertion message & call stack if applicable)
What's the expected result?