10

valgrind detects "still reachable leak" in an empty program compiled with gcc5.1, g++ ./a.cpp, 

int main () {}

valgrind says, valgrind ./a.out,

==32037== HEAP SUMMARY:
==32037==     in use at exit: 72,704 bytes in 1 blocks
==32037==   total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated
==32037== 
==32037== LEAK SUMMARY:
==32037==    definitely lost: 0 bytes in 0 blocks
==32037==    indirectly lost: 0 bytes in 0 blocks
==32037==      possibly lost: 0 bytes in 0 blocks
==32037==    still reachable: 72,704 bytes in 1 blocks
==32037==         suppressed: 0 bytes in 0 blocks
==32037== Rerun with --leak-check=full to see details of leaked memory
==32037== 
==32037== For counts of detected and suppressed errors, rerun with: -v
==32037== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 5)

For c programs, valgrinds reports no memory leaks and no memory allocation. In addition, for gcc5.0 and gcc4.9.2, valgrinds reports no memory leaks and no memory allocation too. Then, I guess that new libstdc++ of gcc5.1 is the cause.

My question is how to reduce this huge memory allocation which may be in libstdc++. Indeed, the execution time of this empty c++ program compiled with -O3 is larger than one of the empty c program by a few milliseconds (without systime).

akakatak
  • 575
  • 3
  • 14
  • is your file *only* `int main () {}` ? or does it have includes, and such? – Eregrith May 22 '15 at 09:39
  • no user specified files are included or linked. `int main () {}` is the content exactly, and `g++ ./a.cpp` is the compile command which I used. – akakatak May 22 '15 at 09:42
  • So it's really only `int main () {}`... wow gcc... wow.... – Eregrith May 22 '15 at 09:43
  • What does `gcc -E a.cpp` gives you? What does the `.o` looks like? – Eregrith May 22 '15 at 09:45
  • 1
    `g++ -E a.cpp` says, 　　　　# 1 "test.cpp" 　　　　# 1 "" 　　　　# 1 "" 　　　　# 1 "test.cpp" 　　　　int main () {} 　 I think that the objfile seems to be usual. There is no unfamilier symbols. Anyway, the link suggested by user657267 may tell something to the point. – akakatak May 22 '15 at 13:05

1 Answers1

9

The space is allocated as an emergency exception buffer in libsup++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

the devs talk of maybe suppressing the trace in Valgrind but presumably nothing was done in the end. The only way of eliminating it from the trace right now would probably be to disable exceptions, but it doesn't look like it's a big deal either way, it's not as if the memory can be reclaimed for something else before the program exits.

user657267
  • 20,568
  • 5
  • 58
  • 77
  • 1
    This definitely needs the suppression in Valgrind, wasted half an hour looking for my leak before I stumbled to this SO thread... – XapaJIaMnu May 28 '15 at 16:06
  • 1
    Looks like they've fixed the problem, now we just have to wait until our distro catches up! – nic Jan 26 '16 at 20:00
  • @nic Do you have any resource about your comment? – akakatak Feb 16 '16 at 05:51
  • 1
    I found this article https://wiki.wxwidgets.org/Valgrind_Suppression_File_Howto useful in telling me how to create a valgrind supression. My supression (for gcc 5.4.0) is { Memcheck:Leak match-leak-kinds: reachable fun:malloc obj:/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 fun:call_init.part.0 fun:call_init fun:_dl_init obj:/lib/x86_64-linux-gnu/ld-2.23.so } – RichardHowells Aug 18 '16 at 01:07