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

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

本文关键字:分配 内存 的新 libstdc++ gcc5      更新时间:2023-10-16

valgrind在使用gcc5.1, g++ ./a.cpp

编译的空程序中检测到"仍可到达的泄漏"
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程序,valgrind不会报告内存泄漏和内存分配。此外,对于gcc5.0和gcc4.9.2, valgrind报告没有内存泄漏,也没有内存分配。那么,我猜gcc5.1的新libstdc++是原因。

我的问题是如何减少这种巨大的内存分配,这可能是在libstdc++。实际上,这个用-O3编译的空c++程序的执行时间比一个空c程序的执行时间要长几毫秒(不含systime)。

空间被分配为libsup++中的紧急异常缓冲区

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

开发人员说可能会在Valgrind中抑制追踪,但最终可能什么都没做。现在从跟踪中消除它的唯一方法可能是禁用异常,但这看起来都不是什么大问题,因为在程序退出之前,内存不能被回收用于其他事情。