nowy libstdC++ z gcc5.1 może przydzielić pamięci duża kupa

Question

valgrind wykrywa "wciąż dostępny przeciek" w pustym programu skompilowanego z gcc5.1, g++ ./a.cpp,

int main() {} 

valgrind mówi 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) 

Dla programów c, valgrinds zgłasza brak wycieków pamięci i brak alokacji pamięci. Ponadto, dla gcc5.0 i gcc4.9.2, valgrinds zgłasza brak wycieków pamięci i brak alokacji pamięci. Następnie, myślę, że przyczyną jest nowy libstdC++ z gcc5.1.

Moje pytanie brzmi: jak zmniejszyć ten ogromny przydział pamięci, który może znajdować się w libstdC++. Rzeczywiście, czas wykonania tego pustego programu C++ skompilowanego z -O3 jest większy niż jeden z pustych programów c o kilka milisekund (bez systime).

Answer 1

Przestrzeń jest przydzielona jako bufor wyjątków awaryjnego w libsup ++

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

rozmowie z deweloperów może tłumiąc ślad w Valgrind ale prawdopodobnie nic nie zostało zrobione w końcu. Jedynym sposobem wyeliminowania go z tego śladu byłoby prawdopodobnie wyłączenie wyjątków, ale nie wygląda na to, że to wielka sprawa w obu przypadkach, to nie jest tak, że pamięć może zostać odzyskana na coś innego, zanim program się zakończy.