Random memory leak in binutils?

[Nile Aagard]

I've just discovered valgrind and have been using it to check for memory 
leaks in a project I've been working on.
But something strange happened that I have just finished proving is 
related to the GCC profiler: without the argument (`-pg') I get 22 
allocs and 22 frees, but with the argument I tend to get 23 allocs and 
22 frees with a fallout of a little more than 16KB as shown in the 
report below:

     $ valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all 
./test.brainbytes
     ==20624== Memcheck, a memory error detector
     ==20624== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward 
et al.
     ==20624== Using Valgrind-3.16.1 and LibVEX; rerun with -h for 
copyright info
     ==20624== Command: ./test.brainbytes
     ==20624==
        [Core] Initialize & Destroy: FAILED
         - [Init] Memory Stack is wrong size.
         - [Init] Function Stack wrong size.
         - [Init] Operator List wrong size.
         - [Init] Thread Tracker wrong size.
     ==20624==
     ==20624== Process terminating with default action of signal 27 
(SIGPROF)
     ==20624==    at 0x4CA026A: __open_nocancel (in /usr/lib/libc-2.33.so)
     ==20624==    by 0x4CAC4FF: write_gmon (in /usr/lib/libc-2.33.so)
     ==20624==    by 0x4CACCBE: _mcleanup (in /usr/lib/libc-2.33.so)
     ==20624==    by 0x4BEAC8D: __cxa_finalize (in /usr/lib/libc-2.33.so)
     ==20624==    by 0x109247: ??? (in /srv/http/build/test.brainbytes)
     ==20624==    by 0x401023A: _dl_fini (in /usr/lib/ld-2.33.so)
     ==20624==    by 0x4BEA696: __run_exit_handlers (in 
/usr/lib/libc-2.33.so)
     ==20624==    by 0x4BEA83D: exit (in /usr/lib/libc-2.33.so)
     ==20624==    by 0x4BD2B2B: (below main) (in /usr/lib/libc-2.33.so)
     ==20624==
     ==20624== HEAP SUMMARY:
     ==20624==     in use at exit: 16,818 bytes in 1 blocks
     ==20624==   total heap usage: 23 allocs, 22 frees, 95,250 bytes 
allocated
     ==20624==
     ==20624== 16,818 bytes in 1 blocks are still reachable in loss 
record 1 of 1
     ==20624==    at 0x4840B65: calloc (vg_replace_malloc.c:760)
     ==20624==    by 0x4CACAF2: monstartup (in /usr/lib/libc-2.33.so)
     ==20624==    by 0x109180: __gmon_start__ (in 
/srv/http/build/test.brainbytes)
     ==20624==    by 0x483E015: ??? (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
     ==20624==    by 0x1FFF0007DF: ???
     ==20624==    by 0x400FE49: call_init.part.0 (in /usr/lib/ld-2.33.so)
     ==20624==    by 0x4010008: _dl_init (in /usr/lib/ld-2.33.so)
     ==20624==    by 0x40010C9: ??? (in /usr/lib/ld-2.33.so)
     ==20624==
     ==20624== LEAK SUMMARY:
     ==20624==    definitely lost: 0 bytes in 0 blocks
     ==20624==    indirectly lost: 0 bytes in 0 blocks
     ==20624==      possibly lost: 0 bytes in 0 blocks
     ==20624==    still reachable: 16,818 bytes in 1 blocks
     ==20624==         suppressed: 0 bytes in 0 blocks
     ==20624==
     ==20624== For lists of detected and suppressed errors, rerun with: -s
     ==20624== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 
from 0)
     Profiling timer expired

NOTE that all lines from valgrind are prefixed by "==20624==" and 
application output is not prefixed, making the most important messages 
the two callstacks from valgrind and the final message from the profiler.
The strange component to all this is that that every few runs this leak 
does not occur and I get 23 frees like there's supposed to be.
By removing the offending argument `-pg' from by compiler and linker 
this issue goes away which verifies to me that the issue is not in my 
code; there's nothing special about my code either, I am only using the 
default libraries.

I don't know exactly where the issue occurs being unfamiliar with ld and 
libc internals, or if the problem is simply the result of a disagreement 
between the profiler and valgrind which is why I dare not file it as a 
bug report.
What I do know is that memory leaks are undesirable, like rebuilding 
with different parameters between tests.
Perhaps you could shed some light on the subject?  Has there been a 
previous case that concluded with the profiler and valgrind just aren't 
designed to work together?  Or is this a "new" issue that has not been 
previously seen?

In any case I appreciate your consideration of this matter, as well as 
your patience with my ignorance.

In total sincerity,
     Nile Aagard