Hide Forgot
Description of problem: In case that C++ client's capacity is set to something greater than 0, its memory consumption grows while receiving and acknowledging messages. I came across this problem while I was trying to verify https://issues.apache.org/jira/browse/QPID-3321. I used "drain" example in my tests, which was modified slightly (the function Receiver::setCapacity() was called right after receiver's creation). The tests show that memory consumption of such a client grows constantly while receiving and acknowledging messages from a broker. The longest testrun I did lasted for 10 hours and during that time, client's memory grew from initial value of 39489KB to 170068KB. Version-Release number of selected component (if applicable): qpid-cpp-client-0.12-6.el6.i686 qpid-cpp-client-devel-0.12-6.el6.i686 qpid-cpp-client-rdma-0.12-6.el6.i686 qpid-cpp-client-ssl-0.12-6.el6.i686 qpid-cpp-debuginfo-0.12-6.el6.i686 qpid-cpp-server-0.12-6.el6.i686 qpid-cpp-server-cluster-0.12-6.el6.i686 qpid-cpp-server-rdma-0.12-6.el6.i686 qpid-cpp-server-ssl-0.12-6.el6.i686 qpid-cpp-server-store-0.12-6.el6.i686 How reproducible: always Steps to Reproduce: 1. Create a C++ client with capacity greater that 0. 2. Let it run and receive lots and lots of messages from a broker. 3. Observe the memory consumption growth (f.e., using pmap). Actual results: Such a client, while running and receiving messages, leeks memory. Expected results: The memory consumption should not grow over time. Additional info: In my tests, I set the client's capacity to 256. The client with 0 capacity seems to be free from this particular problem.
Created attachment 535819 [details] Script to reproduce the bug. Just untar it, change to client_memory_leak directory and type "make run". The test lasts for about 10 minutes, which should be quite enough to reproduce the problem. To make it run longer, adjust the LOOPS_NUM variable in runtest.sh.
Bizarrely, this test passes for me on fedora 12 whether with the 0.10, 0.12 or trunk codebases. It fails on RHEL both for the 0.12 packages listed here (I used RHEL5 variants) and against trunk...
The problem seems to be present on Fedora 15. I ran the test on my laptop (x86_64) for an hour and a half, and client's memory consumption increased from 292308KB to 362135KB.
I can't reproduce it on either 0.18-20 or 0.22-42. Leonid, is the leak still present in either version?
(In reply to Pavel Moravec from comment #6) > I can't reproduce it on either 0.18-20 or 0.22-42. > > Leonid, is the leak still present in either version? I'm unable to reproduce this as well, neither on 0.18 nor on 0.22. I propose to close it, this does not seem to be an issue for the current versions.