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

aka*_*tak 9 c c++ gcc valgrind

valgrind在用gcc5.1编译的空程序中检测到"仍然可到达的泄漏" g++ ./a.cpp,

int main () {}
Run Code Online (Sandbox Code Playgroud)

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)
Run Code Online (Sandbox Code Playgroud)

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

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

use*_*267 8

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

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

开发人员谈论可能会抑制Valgrind中的痕迹,但可能最终没有做任何事情.现在从跟踪中消除它的唯一方法可能是禁用异常,但它看起来不是什么大不了的事情,在程序退出之前就不能回收内存了.