activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Roach (JIRA)" <>
Subject [jira] Commented: (AMQCPP-220) Memory leak in activemq-cpp
Date Fri, 30 Jan 2009 02:37:00 GMT


Brian Roach commented on AMQCPP-220:

Of course, the problem with valgrind is ... if you're using memory pools, it really isn't
going to tell you much.

The problem is that src/main/decaf/util/concurrent/Mutex.cpp continuously apr_palloc()'s memory
via apr_thread_cond_create() without ever releasing it back to the pool. 

This leads to a 20 byte leak every time Mutex::wait() is called (Technically ... not a "leak"
as far as things like valgrind are concerned, because the pool still knows about the memory)
. It appears this Mutex object is never destroyed, so the pool grows forever and isn't destroyed
until the application exits.

The solution is to create a subpool from the AprPool and destroy it after use in Mutex::Wait.
Or,  define a private apr_pool_t* subpool, create it in the constructor, use it for the condition
and call apr_pool_clear() after apr_thread_cond_destroy(), then destroy it in the destructor.
This is more efficient, actually, because you get the memory re-use benefit.

I can submit a patch if you'd like?

- Brian Roach

> Memory leak in activemq-cpp
> ---------------------------
>                 Key: AMQCPP-220
>                 URL:
>             Project: ActiveMQ C++ Client
>          Issue Type: Bug
>          Components: CMS Impl
>    Affects Versions: 2.2.3
>         Environment: Solaris 10 x86
> GCC (g++) 3.4.6 (from 
> APR 1.3.3
> APR-util 1.3.4
>            Reporter: Brian Roach
>            Assignee: Timothy Bish
>            Priority: Critical
> The API leaks ~ 2MB of memory for every 1 million messages consumed.
> The example consumer in activemq-cpp-2.2.3-src/src/examples/consumers can be used as
a test bed, it exhibits the behavior.  
> It's even worse if you are not using the consumer->setMessageListener( ) method and
are instead directly using the consumer->receive() method in your own loop.  I dont' have
hard numbers but it is somewhere around ten-fold. 
> We have an application which is processing ~ 40 million messages per day, and will keep
growing until the box runs out of memory. 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message