Question

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）。

Answer 1

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

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

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

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

1 个答案: