You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by "Rafael H. Schloming (JIRA)" <ji...@apache.org> on 2013/09/25 14:54:03 UTC
[jira] [Commented] (PROTON-424) Memory Leak in Proton Messenger
Send / Recv
[ https://issues.apache.org/jira/browse/PROTON-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13777418#comment-13777418 ]
Rafael H. Schloming commented on PROTON-424:
--------------------------------------------
Hi there, I can confirm that this is in fact a memory leak. I will fix it on trunk shortly.
FYI, you should be able to work around it by modifying your code. The memory leak happens when freeing a messenger that has not been properly stopped. Your messengers aren't being stopped because you call interrupt just prior to calling stop, and so stop returns PN_INTR rather than blocking.
FWIW, I don't think either call to interrupt has any useful effect since you are calling it *after* doing pthread_join, so there are no other threads running at the time which is why you end up interrupting your subsequent calls to stop. I'd suggest either eliminating the calls to interrupt entirely, or modify your subscribe thread to run until it is interrupted and then do the stop in the subscribe thread prior to returning from qpidListenerThread. In this latter case your main thread would do an interrupt on the subscriber listener only, and only then join on the subscriber thread. That way the main thread would be guaranteed the messenger was properly stopped prior to freeing it.
> Memory Leak in Proton Messenger Send / Recv
> -------------------------------------------
>
> Key: PROTON-424
> URL: https://issues.apache.org/jira/browse/PROTON-424
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Affects Versions: 0.5
> Environment: Linux
> Reporter: Frank Quinn
> Attachments: qpid_messenger_leak_repro.c
>
>
> Hi Folks,
> I have encountered what looks like a memory leak in messenger if someone could verify?
> I have attached some code which runs under valgrind --leak-check=full to produce the following output.
> Can anyone verify if there is a way to clean this up or is this a leak in proton-c 0.5?
> Cheers,
> Frank
> ==21663== Memcheck, a memory error detector
> ==21663== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> ==21663== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
> ==21663== Command: ./qpid_messenger_leak_repro
> ==21663==
> Waiting on recv
> ==21663==
> ==21663== HEAP SUMMARY:
> ==21663== in use at exit: 376,057 bytes in 3,417 blocks
> ==21663== total heap usage: 4,110 allocs, 693 frees, 763,143 bytes allocated
> ==21663==
> ==21663== 142,153 (2,776 direct, 139,377 indirect) bytes in 1 blocks are definitely lost in loss record 996 of 997
> ==21663== at 0x4A0887C: malloc (vg_replace_malloc.c:270)
> ==21663== by 0x4C232CF: pn_new (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0)
> ==21663== by 0x4C336AD: pn_connection (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0)
> ==21663== by 0x4C421EC: pn_messenger_connection (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0)
> ==21663== by 0x4C424DC: pn_messenger_tsync (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0)
> ==21663== by 0x4C42695: pn_messenger_sync (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0)
> ==21663== by 0x4C44301: pn_messenger_recv (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0)
> ==21663== by 0x400C43: qpidListenerThread (qpid_messenger_leak_repro.c:18)
> ==21663== by 0x3702407D14: start_thread (pthread_create.c:308)
> ==21663== by 0x37020F253C: clone (clone.S:114)
> ==21663==
> ==21663== 142,168 (2,776 direct, 139,392 indirect) bytes in 1 blocks are definitely lost in loss record 997 of 997
> ==21663== at 0x4A0887C: malloc (vg_replace_malloc.c:270)
> ==21663== by 0x4C232CF: pn_new (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0)
> ==21663== by 0x4C336AD: pn_connection (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0)
> ==21663== by 0x4C421EC: pn_messenger_connection (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0)
> ==21663== by 0x4C42F48: pn_messenger_resolve (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0)
> ==21663== by 0x4C4310B: pn_messenger_link (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0)
> ==21663== by 0x4C4333C: pn_messenger_target (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0)
> ==21663== by 0x4C43DDE: pn_messenger_put (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0)
> ==21663== by 0x400D40: main (qpid_messenger_leak_repro.c:79)
> ==21663==
> ==21663== LEAK SUMMARY:
> ==21663== definitely lost: 5,552 bytes in 2 blocks
> ==21663== indirectly lost: 278,769 bytes in 388 blocks
> ==21663== possibly lost: 0 bytes in 0 blocks
> ==21663== still reachable: 91,736 bytes in 3,027 blocks
> ==21663== suppressed: 0 bytes in 0 blocks
> ==21663== Reachable blocks (those to which a pointer was found) are not shown.
> ==21663== To see them, rerun with: --leak-check=full --show-reachable=yes
> ==21663==
> ==21663== For counts of detected and suppressed errors, rerun with: -v
> ==21663== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira