Qpid Proton
  1. Qpid Proton
  2. PROTON-424

Memory Leak in Proton Messenger Send / Recv

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.5
    • Fix Version/s: 0.6
    • Component/s: proton-c
    • Labels:
      None
    • Environment:
      Linux

      Description

      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)

        Activity

        Hide
        Rafael H. Schloming added a comment -

        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.

        Show
        Rafael H. Schloming added a comment - 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.
        Hide
        ASF subversion and git services added a comment -

        Commit 1526554 from rhs@apache.org in branch 'proton/trunk'
        [ https://svn.apache.org/r1526554 ]

        PROTON-424: fixed memory leak when freeing non stopped messengers

        Show
        ASF subversion and git services added a comment - Commit 1526554 from rhs@apache.org in branch 'proton/trunk' [ https://svn.apache.org/r1526554 ] PROTON-424 : fixed memory leak when freeing non stopped messengers

          People

          • Assignee:
            Rafael H. Schloming
            Reporter:
            Frank Quinn
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development