[
https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785802#action_12785802
]
Stefan Doerfler commented on QPID-2214:
---------------------------------------
Andrew,
nevertheless the patch prevents the unrestrained growth of memory in the
"allThreadsStatuses" datastructure, which happens in Daniel's scenario. But of
course, I'm not familiarized enough with the sourcecode to understand the
background of the design completly.
The valgrind output is indeed not related to the "pseudo-memleak", as the
memory is still accessible via the "allThreadsStatuses" datastructure and
therefore not reported as such.
I'm looking forward to see a clean-solution for this problem. Our program is
designed to open and close the connection for each incoming client request, so
we're affected by the memory growth problem too.
> memory leak in qpid::client::Connection
> ---------------------------------------
>
> Key: QPID-2214
> URL: https://issues.apache.org/jira/browse/QPID-2214
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
> Affects Versions: 0.5
> Environment: qpid 0.5 on a Debian Linux with gcc 4.3.3.
> Reporter: Daniel Etzold
> Assignee: Andrew Stitcher
> Priority: Critical
> Attachments: qpid-memleak.patch
>
>
> Hi,
> 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.
> 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?
> int
> main(int argc, char** argv)
> {
> while (1) {
> qpid::client::Connection connection;
> connection.open("localhost", 5672);
> connection.close();
> }
> }
> Running my test binary with valgrind (the loop is limited to 100 iterations)
> valgrind --leak-check=full ./myqpidtest
> it seems that valgrind does not find any memory leaks.
> =17321== 76 bytes in 1 blocks are definitely lost in loss record 2 of 2
> ==17321== at 0x4007ADE: calloc (vg_replace_malloc.c:279)
> ==17321== by 0x430CD4E7: (within /lib/ld-2.3.6.so)
> ==17321== by 0x430CD58B: _dl_allocate_tls (in /lib/ld-2.3.6.so)
> ==17321== by 0x43AE428F: pthread_create@@GLIBC_2.1 (in
> /lib/tls/i686/cmov/libpthread-2.3.6.so)
> ==17321== by 0x43AE4AA7: pthread_cre...@glibc_2.0 (in
> /lib/tls/i686/cmov/libpthread-2.3.6.so)
> ==17321== by 0x4AA3B55:
> qpid::sys::ThreadPrivate::ThreadPrivate(qpid::sys::Runnable*) (in
> libqpidcommon.so.0.1.0)
> ==17321== by 0x4AA3682: qpid::sys::Thread::Thread(qpid::sys::Runnable*)
> (in libqpidcommon.so.0.1.0)
> ==17321== by 0x4C8BC6B: qpid::client::TCPConnector::init() (in
> libqpidclient.so.0.1.0)
> ==17321== by 0x4C8040A: qpid::client::ConnectionImpl::open() (in
> libqpidclient.so.0.1.0)
> ==17321== by 0x4C6CD4A:
> qpid::client::Connection::open(qpid::client::ConnectionSettings const&) (in
> libqpidclient.so.0.1.0)
> ==17321== by 0x4C6CED2: qpid::client::Connection::open(std::string const&,
> int, std::string const&, std::string const&, std::string const&, unsigned
> short) (in libqpidclient.so.0.1.0)
> ==17321== by 0x805EE1E: main (myqpidtest.cpp:281)
> ==17321==
> ==17321== LEAK SUMMARY:
> ==17321== definitely lost: 76 bytes in 1 blocks.
> ==17321== possibly lost: 0 bytes in 0 blocks.
> ==17321== still reachable: 48 bytes in 3 blocks.
> ==17321== suppressed: 0 bytes in 0 blocks.
> The 76 bytes which are reported to be definitely lost is constant whether
> running the loop 100 time or 1000 times.
> Regards,
> Daniel
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
