Memory leak within the linked library

[joaocandre]

I have found that just by linking libcmaes.so to any particular C++ code will result in a small memory leak. An empty program e.g.

int main(int argc, char const *argv[]){ return 0; }

compiled with g++ test.cpp -lcmaes, when run with valgrind will result in the following output:

==26599== Memcheck, a memory error detector
==26599== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==26599== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==26599== Command: ./a.out
==26599== 
==26599== 
==26599== HEAP SUMMARY:
==26599==     in use at exit: 8 bytes in 1 blocks
==26599==   total heap usage: 243 allocs, 242 frees, 127,072 bytes allocated
==26599== 
==26599== LEAK SUMMARY:
==26599==    definitely lost: 0 bytes in 0 blocks
==26599==    indirectly lost: 0 bytes in 0 blocks
==26599==      possibly lost: 0 bytes in 0 blocks
==26599==    still reachable: 8 bytes in 1 blocks
==26599==         suppressed: 0 bytes in 0 blocks
==26599== Rerun with --leak-check=full to see details of leaked memory
==26599== 
==26599== For counts of detected and suppressed errors, rerun with: -v
==26599== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)`

While a pretty insignificant leak, I've opened the issue because I did not found any reference to it here.

[beniz]

Hi, try valgrind --leak-check=full --trace-children=yes to get a full report.

[joaocandre]

Sorry for the delay, here goes a more verbose output:

==9136== Memcheck, a memory error detector
==9136== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9136== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==9136== Command: ./test
==9136== 
==9136== 
==9136== HEAP SUMMARY:
==9136==     in use at exit: 8 bytes in 1 blocks
==9136==   total heap usage: 243 allocs, 242 frees, 127,072 bytes allocated
==9136== 
==9136== 8 bytes in 1 blocks are still reachable in loss record 1 of 1
==9136==    at 0x483777F: malloc (vg_replace_malloc.c:299)
==9136==    by 0x53D898D: gomp_malloc (alloc.c:37)
==9136==    by 0x53E7C6B: gomp_init_num_threads (proc.c:91)
==9136==    by 0x53D6F0A: initialize_env (env.c:1244)
==9136==    by 0x4010549: call_init.part.0 (in /usr/lib/ld-2.28.so)
==9136==    by 0x4010649: _dl_init (in /usr/lib/ld-2.28.so)
==9136==    by 0x4002039: ??? (in /usr/lib/ld-2.28.so)
==9136== 
==9136== LEAK SUMMARY:
==9136==    definitely lost: 0 bytes in 0 blocks
==9136==    indirectly lost: 0 bytes in 0 blocks
==9136==      possibly lost: 0 bytes in 0 blocks
==9136==    still reachable: 8 bytes in 1 blocks
==9136==         suppressed: 0 bytes in 0 blocks
==9136== 
==9136== For counts of detected and suppressed errors, rerun with: -v
==9136== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

[beniz]

Thanks, that looks fine to me, there's no loss. The reachable 8 bytes appear to be coming from a shared lib init, all clear.

FYI libcmaes uses policy-based templates and avoids pointers almost everywhere, so memory is always on the stack and freed automatically.