gcc5.1 的新 libstdc++ 可能会分配大堆内存

new libstdc++ of gcc5.1 may allocate large heap memory

valgrind 在用 gcc5.1、g++ ./a.cpp

编译的空程序中检测到 "still reachable leak"
int main () {}

valgrind 说,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)

对于 c 程序,valgrinds 报告没有内存泄漏和内存分配。 此外,对于 gcc5.0 和 gcc4.9.2,valgrinds 报告没有内存泄漏,也没有内存分配。 然后,我猜gcc5.1的new libstdc++是原因。

我的问题是如何减少 libstdc++ 中可能存在的巨大内存分配。 事实上,这个用 -O3 编译的空 c++ 程序的执行时间比其中一个空 c 程序多几毫秒(没有 systime)。

space在libsup++

中被分配为紧急异常缓冲区

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

开发人员谈到可能会在 Valgrind 中抑制跟踪,但大概最终什么也没做。现在从跟踪中消除它的唯一方法可能是禁用异常,但无论哪种方式看起来都不是什么大问题,似乎在程序退出之前内存可以回收用于其他东西。