Is it not just that the memory is not needed back yet from Linux? I.e. 
gcc does not really try
to reuse memory until it needs to. If you run for say 30 seconds, then 
stop the client for a few,
and then run it again. Or in the pause in-between start firefox... and 
see if tc_mem_consolidate
is run and it drops back down

Carl.


Daniel Etzold wrote:
> Hi Steve,
> I've created a jira report.
> https://issues.apache.org/jira/browse/QPID-2214
>
> Thanks,
> Daniel
>
>
> On Fri, Nov 20, 2009 at 4:23 PM, Steve Huston <shuston@riverace.com> wrote:
>
>   
>> Hi Daniel,
>>
>>     
>>> when executing the code below (connecting and disconnecting to a
>>>       
>> local
>>     
>>> broker without sending any messages) the memory usage
>>> increases constantly
>>> and rapidly. After 10.000 iterations several hundred
>>> megabytes of resident memory are used.
>>>       
>> Yikes.
>>
>>     
>>> When commenting out the lines "connection.open()" and
>>> "close()" the memory usage does not increase.
>>>
>>> So, is there a memory leak in Connection open/close?
>>>       
>> It appears you may have found one, yes.
>>
>>     
>>> int
>>> main(int argc, char** argv)
>>> {
>>>     while (1) {
>>>         qpid::client::Connection connection;
>>>         connection.open("localhost", 5672);
>>>         connection.close();
>>>     }
>>> }
>>>
>>> I'm running qpid 0.5 on a Debian Linux with gcc 4.3.3.
>>>       
>> Could you maybe run your test under valgrind and get a better idea
>> where the leak is? Also, when you get this information, could you
>> please create a jira report for it?
>> (http://issues.apache.org/jira/browse/qpid) Please attach your test
>> progam and valgrind report.
>>
>> Thanks,
>> -Steve
>>
>> --
>> Steve Huston, Riverace Corporation
>> Total Lifecycle Support for Your Networked Applications
>> http://www.riverace.com
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project:      http://qpid.apache.org
>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>
>>
>>     
>
>