Why does valgrind report a memory leak when calling `pcap_open_offline`?










0















I am trying to figure out if I'm having an idiot moment or if there really is a memory leak in libpcap. I'm running Ubuntu 17.10 and libpcap 1.8.1-5ubuntu1. It seems unlikely that such a mature library would have a leak.



I've cut out everything to make a MVCE, so as a consequence, this code doesn't really do much of anything except demonstrate the leak:



#include <stdio.h>
#include <stdlib.h>
#include <pcap.h>

int main(int argc, char **argv)

char errbuf[PCAP_ERRBUF_SIZE];

pcap_t *fd = pcap_open_offline(argv[1], errbuf);

if (!fd)
printf("error: %sn", errbuf);


free(fd); fd = 0;

return 0;



The valgrind report (emphasis added):



==6871==
==6871== HEAP SUMMARY:
==6871== in use at exit: 262,696 bytes in 2 blocks
==6871== total heap usage: 4 allocs, 2 frees, 267,432 bytes allocated
==6871==
==6871== Searching for pointers to 2 not-freed blocks
==6871== Checked 73,072 bytes
==6871==
==6871== 262,144 bytes in 1 blocks are definitely lost in loss record 2 of 2
==6871== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6871== by 0x4E5B89F: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1)
==6871== by 0x4E5AE5C: pcap_fopen_offline_with_tstamp_precision (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1)
==6871== by 0x4E5B05D: pcap_open_offline_with_tstamp_precision (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1)
==6871== by 0x1087A0: main (test.c:9)

==6871==
==6871== LEAK SUMMARY:
==6871== definitely lost: 262,144 bytes in 1 blocks
==6871== indirectly lost: 0 bytes in 0 blocks
==6871== possibly lost: 0 bytes in 0 blocks
==6871== still reachable: 552 bytes in 1 blocks
==6871== suppressed: 0 bytes in 0 blocks
==6871== Reachable blocks (those to which a pointer was found) are not shown.
==6871== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==6871==
==6871== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==6871== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)









share|improve this question


























    0















    I am trying to figure out if I'm having an idiot moment or if there really is a memory leak in libpcap. I'm running Ubuntu 17.10 and libpcap 1.8.1-5ubuntu1. It seems unlikely that such a mature library would have a leak.



    I've cut out everything to make a MVCE, so as a consequence, this code doesn't really do much of anything except demonstrate the leak:



    #include <stdio.h>
    #include <stdlib.h>
    #include <pcap.h>

    int main(int argc, char **argv)

    char errbuf[PCAP_ERRBUF_SIZE];

    pcap_t *fd = pcap_open_offline(argv[1], errbuf);

    if (!fd)
    printf("error: %sn", errbuf);


    free(fd); fd = 0;

    return 0;



    The valgrind report (emphasis added):



    ==6871==
    ==6871== HEAP SUMMARY:
    ==6871== in use at exit: 262,696 bytes in 2 blocks
    ==6871== total heap usage: 4 allocs, 2 frees, 267,432 bytes allocated
    ==6871==
    ==6871== Searching for pointers to 2 not-freed blocks
    ==6871== Checked 73,072 bytes
    ==6871==
    ==6871== 262,144 bytes in 1 blocks are definitely lost in loss record 2 of 2
    ==6871== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==6871== by 0x4E5B89F: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1)
    ==6871== by 0x4E5AE5C: pcap_fopen_offline_with_tstamp_precision (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1)
    ==6871== by 0x4E5B05D: pcap_open_offline_with_tstamp_precision (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1)
    ==6871== by 0x1087A0: main (test.c:9)

    ==6871==
    ==6871== LEAK SUMMARY:
    ==6871== definitely lost: 262,144 bytes in 1 blocks
    ==6871== indirectly lost: 0 bytes in 0 blocks
    ==6871== possibly lost: 0 bytes in 0 blocks
    ==6871== still reachable: 552 bytes in 1 blocks
    ==6871== suppressed: 0 bytes in 0 blocks
    ==6871== Reachable blocks (those to which a pointer was found) are not shown.
    ==6871== To see them, rerun with: --leak-check=full --show-leak-kinds=all
    ==6871==
    ==6871== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
    ==6871== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)









    share|improve this question
























      0












      0








      0








      I am trying to figure out if I'm having an idiot moment or if there really is a memory leak in libpcap. I'm running Ubuntu 17.10 and libpcap 1.8.1-5ubuntu1. It seems unlikely that such a mature library would have a leak.



      I've cut out everything to make a MVCE, so as a consequence, this code doesn't really do much of anything except demonstrate the leak:



      #include <stdio.h>
      #include <stdlib.h>
      #include <pcap.h>

      int main(int argc, char **argv)

      char errbuf[PCAP_ERRBUF_SIZE];

      pcap_t *fd = pcap_open_offline(argv[1], errbuf);

      if (!fd)
      printf("error: %sn", errbuf);


      free(fd); fd = 0;

      return 0;



      The valgrind report (emphasis added):



      ==6871==
      ==6871== HEAP SUMMARY:
      ==6871== in use at exit: 262,696 bytes in 2 blocks
      ==6871== total heap usage: 4 allocs, 2 frees, 267,432 bytes allocated
      ==6871==
      ==6871== Searching for pointers to 2 not-freed blocks
      ==6871== Checked 73,072 bytes
      ==6871==
      ==6871== 262,144 bytes in 1 blocks are definitely lost in loss record 2 of 2
      ==6871== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==6871== by 0x4E5B89F: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1)
      ==6871== by 0x4E5AE5C: pcap_fopen_offline_with_tstamp_precision (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1)
      ==6871== by 0x4E5B05D: pcap_open_offline_with_tstamp_precision (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1)
      ==6871== by 0x1087A0: main (test.c:9)

      ==6871==
      ==6871== LEAK SUMMARY:
      ==6871== definitely lost: 262,144 bytes in 1 blocks
      ==6871== indirectly lost: 0 bytes in 0 blocks
      ==6871== possibly lost: 0 bytes in 0 blocks
      ==6871== still reachable: 552 bytes in 1 blocks
      ==6871== suppressed: 0 bytes in 0 blocks
      ==6871== Reachable blocks (those to which a pointer was found) are not shown.
      ==6871== To see them, rerun with: --leak-check=full --show-leak-kinds=all
      ==6871==
      ==6871== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
      ==6871== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)









      share|improve this question














      I am trying to figure out if I'm having an idiot moment or if there really is a memory leak in libpcap. I'm running Ubuntu 17.10 and libpcap 1.8.1-5ubuntu1. It seems unlikely that such a mature library would have a leak.



      I've cut out everything to make a MVCE, so as a consequence, this code doesn't really do much of anything except demonstrate the leak:



      #include <stdio.h>
      #include <stdlib.h>
      #include <pcap.h>

      int main(int argc, char **argv)

      char errbuf[PCAP_ERRBUF_SIZE];

      pcap_t *fd = pcap_open_offline(argv[1], errbuf);

      if (!fd)
      printf("error: %sn", errbuf);


      free(fd); fd = 0;

      return 0;



      The valgrind report (emphasis added):



      ==6871==
      ==6871== HEAP SUMMARY:
      ==6871== in use at exit: 262,696 bytes in 2 blocks
      ==6871== total heap usage: 4 allocs, 2 frees, 267,432 bytes allocated
      ==6871==
      ==6871== Searching for pointers to 2 not-freed blocks
      ==6871== Checked 73,072 bytes
      ==6871==
      ==6871== 262,144 bytes in 1 blocks are definitely lost in loss record 2 of 2
      ==6871== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==6871== by 0x4E5B89F: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1)
      ==6871== by 0x4E5AE5C: pcap_fopen_offline_with_tstamp_precision (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1)
      ==6871== by 0x4E5B05D: pcap_open_offline_with_tstamp_precision (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1)
      ==6871== by 0x1087A0: main (test.c:9)

      ==6871==
      ==6871== LEAK SUMMARY:
      ==6871== definitely lost: 262,144 bytes in 1 blocks
      ==6871== indirectly lost: 0 bytes in 0 blocks
      ==6871== possibly lost: 0 bytes in 0 blocks
      ==6871== still reachable: 552 bytes in 1 blocks
      ==6871== suppressed: 0 bytes in 0 blocks
      ==6871== Reachable blocks (those to which a pointer was found) are not shown.
      ==6871== To see them, rerun with: --leak-check=full --show-leak-kinds=all
      ==6871==
      ==6871== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
      ==6871== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)






      c linux memory-leaks valgrind libpcap






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 15 '18 at 4:41









      Greg SchmitGreg Schmit

      2,21121227




      2,21121227






















          1 Answer
          1






          active

          oldest

          votes


















          2














          From the libpcap manpage,
          edited slightly:




          pcap_fopen_offline() return[s] a pointer to a pcap_t, which is the handle used for reading packets… To close a handle, use pcap_close().




          free(fd) just frees a single block of memory, since free() knows nothing about the internals of a pcap_t. In order to properly dispose of allocated resources, you need to use pcap_close(fd) instead, as the documentation indicates.






          share|improve this answer























          • Ah, thanks! I was looking at the man page of pcap_open_offline() (tcpdump.org/manpages/pcap_open_offline.3pcap.html) and it didn't mention that.

            – Greg Schmit
            Nov 16 '18 at 0:26










          Your Answer






          StackExchange.ifUsing("editor", function ()
          StackExchange.using("externalEditor", function ()
          StackExchange.using("snippets", function ()
          StackExchange.snippets.init();
          );
          );
          , "code-snippets");

          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "1"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53312543%2fwhy-does-valgrind-report-a-memory-leak-when-calling-pcap-open-offline%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          2














          From the libpcap manpage,
          edited slightly:




          pcap_fopen_offline() return[s] a pointer to a pcap_t, which is the handle used for reading packets… To close a handle, use pcap_close().




          free(fd) just frees a single block of memory, since free() knows nothing about the internals of a pcap_t. In order to properly dispose of allocated resources, you need to use pcap_close(fd) instead, as the documentation indicates.






          share|improve this answer























          • Ah, thanks! I was looking at the man page of pcap_open_offline() (tcpdump.org/manpages/pcap_open_offline.3pcap.html) and it didn't mention that.

            – Greg Schmit
            Nov 16 '18 at 0:26















          2














          From the libpcap manpage,
          edited slightly:




          pcap_fopen_offline() return[s] a pointer to a pcap_t, which is the handle used for reading packets… To close a handle, use pcap_close().




          free(fd) just frees a single block of memory, since free() knows nothing about the internals of a pcap_t. In order to properly dispose of allocated resources, you need to use pcap_close(fd) instead, as the documentation indicates.






          share|improve this answer























          • Ah, thanks! I was looking at the man page of pcap_open_offline() (tcpdump.org/manpages/pcap_open_offline.3pcap.html) and it didn't mention that.

            – Greg Schmit
            Nov 16 '18 at 0:26













          2












          2








          2







          From the libpcap manpage,
          edited slightly:




          pcap_fopen_offline() return[s] a pointer to a pcap_t, which is the handle used for reading packets… To close a handle, use pcap_close().




          free(fd) just frees a single block of memory, since free() knows nothing about the internals of a pcap_t. In order to properly dispose of allocated resources, you need to use pcap_close(fd) instead, as the documentation indicates.






          share|improve this answer













          From the libpcap manpage,
          edited slightly:




          pcap_fopen_offline() return[s] a pointer to a pcap_t, which is the handle used for reading packets… To close a handle, use pcap_close().




          free(fd) just frees a single block of memory, since free() knows nothing about the internals of a pcap_t. In order to properly dispose of allocated resources, you need to use pcap_close(fd) instead, as the documentation indicates.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 15 '18 at 5:31









          ricirici

          156k20135205




          156k20135205












          • Ah, thanks! I was looking at the man page of pcap_open_offline() (tcpdump.org/manpages/pcap_open_offline.3pcap.html) and it didn't mention that.

            – Greg Schmit
            Nov 16 '18 at 0:26

















          • Ah, thanks! I was looking at the man page of pcap_open_offline() (tcpdump.org/manpages/pcap_open_offline.3pcap.html) and it didn't mention that.

            – Greg Schmit
            Nov 16 '18 at 0:26
















          Ah, thanks! I was looking at the man page of pcap_open_offline() (tcpdump.org/manpages/pcap_open_offline.3pcap.html) and it didn't mention that.

          – Greg Schmit
          Nov 16 '18 at 0:26





          Ah, thanks! I was looking at the man page of pcap_open_offline() (tcpdump.org/manpages/pcap_open_offline.3pcap.html) and it didn't mention that.

          – Greg Schmit
          Nov 16 '18 at 0:26



















          draft saved

          draft discarded
















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53312543%2fwhy-does-valgrind-report-a-memory-leak-when-calling-pcap-open-offline%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          這個網誌中的熱門文章

          How to read a connectionString WITH PROVIDER in .NET Core?

          In R, how to develop a multiplot heatmap.2 figure showing key labels successfully

          Museum of Modern and Contemporary Art of Trento and Rovereto