该应用程序在Ubuntu Linux上运行,它具有大量的多媒体内容,并使用OpenGl,SDL和ffmpeg用于各种目的,包括3D图形渲染,窗口,音频和电影播放.您可以将其视为视频游戏,虽然它不是,但通过将其视为视频游戏,可以简化应用程序的职责.
我目前有点无能为力地确定我们是否还有内存泄漏.在过去,我们已经确定了一些,并删除了它们.这些天,应用程序已接近完成,我们运行的测试给了我一些我无法弄清楚的结果.
我做的第一件事是尝试通过Valgrind运行应用程序…不幸的是,当在valgrind环境中运行时应用程序崩溃. “非确定性”崩溃,因为它在各个不同的地方崩溃.所以我放弃了Valgrind来轻松识别潜在泄漏的来源,并最终使用了两个Linux命令：free和top.
在应用程序运行时,free用于探测系统内存使用情况
top与’-p’选项一起使用,以在运行时探测应用程序进程内存使用情况.
输出表单top和free将被转储到文件中以进行后处理.我用问题底部链接的数据组成了两个图表.
测试用例非常简单：一旦应用程序启动并等待命令,就会探测有关内存的数据.然后我开始一系列命令,这些命令反复执行相同的操作.该应用程序有望将大量多媒体数据加载到RAM中,然后下载.
不幸的是,图表没有显示我的期望.内存使用量通过3个不同的步骤增长,然后停止.内存显然从未发布,这暗示我有一个巨大的内存泄漏.这将是完全正常的,因为这意味着我们很可能没有释放被媒体吸收的记忆.
但是在前三个步骤之后…内存使用情况稳定……没有更大的步骤……只是轻微的上下,这与预期的数据加载和卸载相对应.这里出乎意料的是,应该加载/卸载的数据占据了百万兆字节的RAM,而不是只有少数兆字节的数据(比如8-10 MB).
我目前在解释这些数据时非常无能为力.
任何人都有一些提示或建议吗？我错过了什么？我用来检查宏观内存泄漏是否存在完全错误的方法？你知道Valgrind以外的任何其他(最好是免费的)工具来检查内存泄漏吗？
解决方法
and we reached the point when it is mandatory to make a roundup of checks for memory leaks.
实际上,这是方法论的问题.正确性应该是任何软件的主要目标,而不是事后的想法.
我想虽然您现在已经意识到这一点,但是如果您在每次提交时都运行了一个检测单元测试,那么识别问题会更容易.
那么,现在该怎么办？
>运行时检测：
>尝试让Valgrind工作,你可能有一些环境问题
>尝试ASan,ThreadSan和MemSan;在Linux下安装它们并不容易,但是真是太棒了！
>尝试检测构建：tcmalloc包括heap-checker
> ……
>编译时间检测：
>打开警告(最好使用-Werror)(不是特定于您的问题)
>使用静态分析,例如Clang’s,它可能会发现不成对的分配例程
> ……
>人体检测：
>代码评审：确保所有资源都在RAII课程中分配
> ……
注意：仅使用RAII类有助于消除内存泄漏,但对悬空引用没有帮助.值得庆幸的是,检测悬空参考是ASan所做的.
一旦您修复了所有问题,请确保这成为流程的一部分.应始终对变更进行审查和测试,以便立即剔除腐烂的鸡蛋,而不是让代码库变臭.
