You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Daniel Etzold (JIRA)" <qp...@incubator.apache.org> on 2009/11/23 10:16:47 UTC
[jira] Created: (QPID-2214) memory leak in qpid::client::Connection
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
Priority: Critical
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_create@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-subscribe@qpid.apache.org
[jira] Assigned: (QPID-2214) memory leak in
qpid::client::Connection
Posted by "Alan Conway (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Conway reassigned QPID-2214:
---------------------------------
Assignee: Andrew Stitcher
> 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
>
> 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_create@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-subscribe@qpid.apache.org
[jira] Commented: (QPID-2214) memory leak in
qpid::client::Connection
Posted by "Stefan Doerfler (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785241#action_12785241 ]
Stefan Doerfler commented on QPID-2214:
---------------------------------------
I've tracked down the memleak in
/src/qpid/sys/DeletionManager.h:
"static AllThreadsStatuses allThreadsStatuses" is static and therfore lives forever, so the dtor is never called during runtime (which would call deleter() for all stored ThreadStatus-Objects).
So "allThreadsStatuses" grows and grows during runtime.
Possible fix:
When a ThreadStatus is destroyed, also remove it from "allThreadsStatuses".
Patch append.
> 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
>
> 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_create@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-subscribe@qpid.apache.org
[jira] Commented: (QPID-2214) memory leak in
qpid::client::Connection
Posted by "Andrew Stitcher (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787067#action_12787067 ]
Andrew Stitcher commented on QPID-2214:
---------------------------------------
I've committed a change on the trunk branch for the memory leak, that is going into 0.6 which is to be released soon.
> 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, qpid-memleak2.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_create@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-subscribe@qpid.apache.org
[jira] Updated: (QPID-2214) memory leak in qpid::client::Connection
Posted by "Andrew Stitcher (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Stitcher updated QPID-2214:
----------------------------------
Fix Version/s: 0.6
> 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
> Fix For: 0.6
>
> Attachments: qpid-memleak.patch, qpid-memleak2.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_create@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-subscribe@qpid.apache.org
[jira] Commented: (QPID-2214) memory leak in
qpid::client::Connection
Posted by "Daniel Etzold (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784133#action_12784133 ]
Daniel Etzold commented on QPID-2214:
-------------------------------------
Hi,
are there any news regarding this problem?
Regards,
Daniel
> 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
>
> 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_create@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-subscribe@qpid.apache.org
[jira] Updated: (QPID-2214) memory leak in qpid::client::Connection
Posted by "Stefan Doerfler (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Doerfler updated QPID-2214:
----------------------------------
Attachment: qpid-memleak.patch
Patch for pseudo-memleak in DeletionManager
> 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_create@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-subscribe@qpid.apache.org
[jira] Resolved: (QPID-2214) memory leak in
qpid::client::Connection
Posted by "Andrew Stitcher (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Stitcher resolved QPID-2214.
-----------------------------------
Resolution: Fixed
The growth in memory for each open/close of a connection has been removed.
The valgrind ttrace (which is an entirely different bug) remains.
> 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
> Fix For: 0.6
>
> Attachments: qpid-memleak.patch, qpid-memleak2.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_create@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-subscribe@qpid.apache.org
[jira] Commented: (QPID-2214) memory leak in
qpid::client::Connection
Posted by "Andrew Stitcher (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785436#action_12785436 ]
Andrew Stitcher commented on QPID-2214:
---------------------------------------
Incidentally,as Daniel implies, I don't think that the valgrind output is related at all to the "memory leak".
The valgrind detected problem appears to happen when a thread isn't properly joined before the program exits and so doesn't clean up the thread specific data that it has allocated.
> 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_create@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-subscribe@qpid.apache.org
[jira] Commented: (QPID-2214) memory leak in
qpid::client::Connection
Posted by "Andrew Stitcher (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785428#action_12785428 ]
Andrew Stitcher commented on QPID-2214:
---------------------------------------
The "correct" way to fix this is to ensure that you never create an unbounded number of io threads.
The design intention was always that the number of io threads was small and fixed, and the client code breaks that intention.
I'm looking at a fix that stops the client code from creating and then destroying a thread per connection.
> 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_create@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-subscribe@qpid.apache.org
[jira] Issue Comment Edited: (QPID-2214) memory leak in
qpid::client::Connection
Posted by "Andrew Stitcher (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785425#action_12785425 ]
Andrew Stitcher edited comment on QPID-2214 at 12/3/09 6:15 PM:
----------------------------------------------------------------
Good work for isolating this "unbounded growth" scenario when creating and then destroying io worker threads.
However I don't see how the patch can fix the diagnosed problem.
There is no way to call the ThreadStatus destructor presently except when shutting the entire program down, in other words during the call of the allThreadsStatus destructor.
The individual ThreadStatus instances aren't deleted on each thread being destroyed and I don't think there is a way to make this happen.
I'm currently thinking about this.
was (Author: astitcher):
Good work for isolating this "unbounded growth" scenario when creating and then destroying io worker threads.
However I don't see how the patch can fix the diagnosed problem.
There is no way to call the ThreadStatus destructor presently except when shutting the entire program dow, in other words during the call of the allThreadsStatus destructor.
The individual ThreadStatus instances aren't deleted on each thread being destroyed and I don't think there is a way to make this happen.
I'm currently thinking about this.
> 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_create@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-subscribe@qpid.apache.org
[jira] Commented: (QPID-2214) memory leak in
qpid::client::Connection
Posted by "Andrew Stitcher (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787069#action_12787069 ]
Andrew Stitcher commented on QPID-2214:
---------------------------------------
The committed fix isn't the amended patch for a few reasons - I worked on it based on the original mostly on Friday (before the amended patch was here).
The amended patch introduces an entirely new library dependency to qpid, and justifying this is significant.
> 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, qpid-memleak2.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_create@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-subscribe@qpid.apache.org
[jira] Issue Comment Edited: (QPID-2214) memory leak in
qpid::client::Connection
Posted by "Stefan Doerfler (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785241#action_12785241 ]
Stefan Doerfler edited comment on QPID-2214 at 12/3/09 2:45 PM:
----------------------------------------------------------------
I've tracked down the memleak in
/src/qpid/sys/DeletionManager.h:
"static AllThreadsStatuses allThreadsStatuses" is static and therfore lives forever, so the dtor is never called during runtime (which would call deleter() for all stored ThreadStatus-Objects).
So "allThreadsStatuses" grows and grows during runtime.
Possible fix:
When a ThreadStatus is destroyed, also remove it from "allThreadsStatuses".
Patch appended.
btw: The latest trunk is also affected.
was (Author: sdo):
I've tracked down the memleak in
/src/qpid/sys/DeletionManager.h:
"static AllThreadsStatuses allThreadsStatuses" is static and therfore lives forever, so the dtor is never called during runtime (which would call deleter() for all stored ThreadStatus-Objects).
So "allThreadsStatuses" grows and grows during runtime.
Possible fix:
When a ThreadStatus is destroyed, also remove it from "allThreadsStatuses".
Patch append.
> 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_create@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-subscribe@qpid.apache.org
[jira] Updated: (QPID-2214) memory leak in qpid::client::Connection
Posted by "Stefan Doerfler (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Doerfler updated QPID-2214:
----------------------------------
Attachment: qpid-memleak2.patch
Fixed version: now the destructor gets called
> 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, qpid-memleak2.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_create@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-subscribe@qpid.apache.org
[jira] Commented: (QPID-2214) memory leak in
qpid::client::Connection
Posted by "Andrew Stitcher (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785425#action_12785425 ]
Andrew Stitcher commented on QPID-2214:
---------------------------------------
Good work for isolating this "unbounded growth" scenario when creating and then destroying io worker threads.
However I don't see how the patch can fix the diagnosed problem.
There is no way to call the ThreadStatus destructor presently except when shutting the entire program dow, in other words during the call of the allThreadsStatus destructor.
The individual ThreadStatus instances aren't deleted on each thread being destroyed and I don't think there is a way to make this happen.
I'm currently thinking about this.
> 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_create@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-subscribe@qpid.apache.org
[jira] Commented: (QPID-2214) memory leak in
qpid::client::Connection
Posted by "Stefan Doerfler (JIRA)" <qp...@incubator.apache.org>.
[ 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_create@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-subscribe@qpid.apache.org