Memory Leak under FreeBSD 6.0 RELEASE

[Arun Balakrishnan (WT01 - Computing, Storage & Software Products)]

   Hi,
   We are currently working on a project wherein we are porting a library
   from GNU/Linux to FreeBSD 6.0 - RELEASE 32-bit and 64-bit. As part of
   the standard memory leak tests, we noticed that the ported library is
   leaking memory. After lots of analysis we found something very
   strange. Just repeatedly loading and unloading our library was itself
   throwing up a leak. We are able to reproduce a similar leak using the
   following steps:
   1. SimpleLib.cpp - Simple dummy library
   2. LibLoader.cpp - Utility to repeatedly load the library
   3. Compile as mentioned
   4. Run under Valgrind for multiple times (31 times in our example.
   Hard coded for simpilicity)
   =================SimpleLib.cpp===================
   #include <stdio.h>
   #include <stdlib.h>
   class CLeaker
   {
   public:
     CLeaker() { };
     virtual ~CLeaker() { };
   };
   CLeaker obj;
   ================LibLoader.cpp======================
   #include "stdio.h"
   #include "dlfcn.h"
   #include <stdlib.h>
   #include <unistd.h>
   #include <sys/time.h>
   int main()
   {
     int i = 0;
     int loop = 31;
     while (i<loop)
       {
         i++;
         void *handle = dlopen(argv[1], RTLD_LAZY);
         if ( !handle )
           exit(1);
         dlclose(handle);
       }
     return 0;
   }
   ======================================================================
   ==
   Compilation:
   g++ -shared -Wl,-soname,SimpleLib.so -o SimpleLib.so SimpleLib.cpp -g
   g++ -o LibLoader_FreeBSD LibLoader.cpp -g
   ======================================================================
   ===
   Execution:
   valgrind --trace-pthread=all --show-below-main=yes
   --show-reachable=yes --leak-check=yes ./LibLoader_FreeBSD
   ./SimpleLib.so
   ======================================================================
   ===
   Output: (snipped off irrelevant portions)
   ==1155== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from
   0)
   ==1155== malloc/free: in use at exit: 520 bytes in 1 blocks.
   ==1155== malloc/free: 1 allocs, 0 frees, 520 bytes allocated.
   ==1155== For counts of detected errors, rerun with: -v
   ==1155== searching for pointers to 1 not-freed blocks.
   ==1155== checked 2140912 bytes.
   ==1155==
   ==1155== 520 bytes in 1 blocks are still reachable in loss record 1 of
   1
   ==1155==    at 0x3C032183: malloc (in
   /usr/local/lib/valgrind/vgpreload_memcheck.so)
   ==1155==    by 0x3C1CB018: (within /lib/libc.so.6)
   ==1155==    by 0x3C1CB206: __cxa_atexit (in /lib/libc.so.6)
   ==1155==    by 0x3C1F0898: ???
   ==1155==
   ==1155== LEAK SUMMARY:
   ==1155==    definitely lost: 0 bytes in 0 blocks.
   ==1155==    possibly lost:   0 bytes in 0 blocks.
   ==1155==    still reachable: 520 bytes in 1 blocks.
   ==1155==         suppressed: 0 bytes in 0 blocks.
   ======================================================================
   ===
   Queries:
   1. As seen in the Valgrind output, there is a 520bytes leak. This
   happens only after around 31 loops and keeps increasing. By 100 loops,
   the leak goes up to 1560 bytes. In our situation with our library, the
   520bytes leak starts by the third iteration itself and by around 23
   iterations it reaches 5KB. We are really stumped as to what could be
   the possible reason for this leak? Where is the malloc called from?
   Why only after executing 31 times? Executing the same code under
   GNU/Linux does not show any leak even for over 1000 iterations.
   2. While executing this without Valgrind, in another terminal we did a
   "ps -Aopid,rss | grep LibLoader_" continuously in a loop and saw that
   the RSS (resident set size) field value keeps increasing by 4KB every
   now and then. The same experiment on GNU/Linux shows that RSS remains
   at the same value. What could be the cause for the ever rising RSS
   value?
   Any help in this regard would be really helpful. Thanks in advance.
   Rgds,
   ~Arun

   The information contained in this electronic message and any
   attachments to this message are intended for the exclusive use of the
   addressee(s) and may contain proprietary, confidential or privileged
   information. If you are not the intended recipient, you should not
   disseminate, distribute or copy this e-mail. Please notify the sender
   immediately and destroy all copies of this message and any
   attachments.

   WARNING: Computer viruses can be transmitted via email. The recipient
   should check this email and any attachments for the presence of
   viruses. The company accepts no liability for any damage caused by any
   virus transmitted by this email.

   www.wipro.com