gcc5.1的新libstdc ++可能分配大的堆内存 [英] new libstdc++ of gcc5.1 may allocate large heap memory

查看:223
本文介绍了gcc5.1的新libstdc ++可能分配大的堆内存的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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


$ b编译的空白程序中检测到仍可达到泄漏 $ b

  int main(){} 

valgrind valgrind ./a.out

  == 32037 = = HEAP摘要:
== 32037 ==在退出时使用:72,704字节在1块
== 32037 ==总堆使用:1分配,0释放,72,704字节分配
= = 32037 ==
== 32037 == LEAK摘要:
== 32037 ==明确丢失:0个块在0块
== 32037 ==间接丢失:0个块在0块
== 32037 ==可能丢失:0块在0块
== 32037 ==仍然可达:72,704字节在1块
== 32037 ==被抑制:0块0块
== 32037 ==重新运行--leak-check = full以查看泄漏内存的详细信息
== 32037 ==
== 32037 ==对于检测到的和抑制的错误计数,重新运行:-v
== 32037 == ERROR摘要:0个上下文中的0个错误(抑制:5从5开始)

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



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

解决方案

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



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



开发人员谈论可能抑制Valgrind中的痕迹,但大概没有做到最后。从现在的迹象中消除它的唯一方法可能是禁用异常,但它看起来不像是一个大问题,无论是哪一种方式,它不像内存可以在程序退出之前收回别的东西。 / p>

valgrind detects "still reachable leak" in an empty program compiled with gcc5.1, g++ ./a.cpp,

int main () {}

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

For c programs, valgrinds reports no memory leaks and no memory allocation. In addition, for gcc5.0 and gcc4.9.2, valgrinds reports no memory leaks and no memory allocation too. Then, I guess that new libstdc++ of gcc5.1 is the cause.

My question is how to reduce this huge memory allocation which may be in libstdc++. Indeed, the execution time of this empty c++ program compiled with -O3 is larger than one of the empty c program by a few milliseconds (without systime).

解决方案

The space is allocated as an emergency exception buffer in libsup++

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

the devs talk of maybe suppressing the trace in Valgrind but presumably nothing was done in the end. The only way of eliminating it from the trace right now would probably be to disable exceptions, but it doesn't look like it's a big deal either way, it's not as if the memory can be reclaimed for something else before the program exits.

这篇关于gcc5.1的新libstdc ++可能分配大的堆内存的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆