[
https://issues.apache.org/activemq/browse/AMQCPP-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49031#action_49031
]
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: https://issues.apache.org/activemq/browse/AMQCPP-220
> 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 www.sunfreeware.com)
> 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.
