Random memory leak in binutils?

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

Re: Random memory leak in binutils?

[Nick Clifton]

Hi Nile,

> 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:
This is really more of a question for the gcc folks, rather than the
binutils, since -pg is a compiler option, not a linker option.
Nevertheless I will attempt to provide an answer for you.

The thing is, the -pg option adds extra code to your compiled program
and involves linking in different versions of the C runtime startup code
(crt1.o vs gcrt1.o).  You can see this for yourself if you compile with
the -v option added to the command line and compare the output when add
or remove the -pg option.

So it is almost certain that the memory leak is coming from this alternate
startup file.  Given what the -pg option does I would guess that the
startup code allocates memory to contain the profiling information that
is generated as the code runs.

Cheers
   Nick

PS.  As an aside I would suggest that worrying about memory leaks is only
important if your program is intended to run for a long time.  And worrying
about memory leaks when trying to profile the program is just not worth it.