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

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程序,valgrinds报告没有内存泄漏和内存分配。 此外,对于gcc5.0和gcc4.9.2,valgrinds报告没有内存泄漏,也没有内存分配。 然后,我猜gcc5.1的新libstdc ++是原因。

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

该空间在libsup ++中被分配为紧急exception缓冲区

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

开发人员谈论可能会抑制Valgrind中的痕迹,但可能最终没有做任何事情。 现在从跟踪中消除它的唯一方法可能是禁用exception,但它看起来不像是一个大问题,它不像在程序退出之前可以为其他东西回收内存。