nuovo libstdC++ di gcc5.1 può allocare memoria gran mucchio

Question

valgrind rileva "ancora raggiungibile fuga" in un programma vuoto compilato con gcc5.1, g++ ./a.cpp,

int main() {} 

valgrind dice 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) 

Per i programmi c, le valgrinds non rilevano perdite di memoria e nessuna allocazione di memoria. Inoltre, per gcc5.0 e gcc4.9.2, valgrinds non segnala perdite di memoria e nessuna allocazione di memoria. Quindi, suppongo che la nuova libstdC++ di gcc5.1 sia la causa.

La mia domanda è come ridurre questa enorme allocazione di memoria che potrebbe essere in libstdC++. In effetti, il tempo di esecuzione di questo programma C++ vuoto compilato con -O3 è maggiore di uno del programma c vuoto di pochi millisecondi (senza systime).

Answer 1

Lo spazio è ripartito come un buffer un'eccezione di emergenza in libsup ++

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

il discorso sviluppatori di forse sopprimere la traccia nella Valgrind ma presumibilmente nulla è stato fatto alla fine. L'unico modo per eliminarlo dalla traccia in questo momento sarebbe probabilmente quello di disabilitare le eccezioni, ma non sembra che sia un grosso problema in entrambi i casi, non è come se la memoria potesse essere recuperata per qualcos'altro prima che il programma uscisse.