我目前正在从事一个大型应用程序项目(用 c++ 编写),该项目是前一段时间从头开始的,我们已经到了必须对内存泄漏进行综合检查的地步。
该应用程序在 Ubuntu Linux 上运行,具有大量多媒体内容,并使用 OpenGl、SDL 和 ffmpeg 用于各种用途,包括 3D 图形渲染、窗口、音频和电影播放。您可以将其视为视频游戏,尽管它不是,但应用程序的职责可以通过将其视为视频游戏来简化。
我目前在确定我们是否仍然存在内存泄漏方面有点无能为力。过去我们已经识别了一些,并删除了它们。不过,这些天来,应用程序几乎完成了,我们运行的测试给了我我无法完全弄清楚的结果。
我做的第一件事是尝试通过 Valgrind 运行应用程序......不幸的是,在 valgrind 环境中运行时应用程序崩溃。“非确定性”的崩溃,因为它在不同的地方崩溃。所以我放弃了使用 Valgrind 来轻松识别潜在泄漏的来源,并最终使用了两个 Linux 命令:free 和 top。
free 用于在应用程序运行时探测系统内存使用情况
top 与“-p”选项一起使用,以在运行时探测应用程序进程的内存使用情况。
输出表单 top 和 free 被转储到文件中以进行后处理。我用问题底部链接的数据制作了两个图表。
测试用例非常简单:一旦应用程序已经启动并等待命令,就会探测有关内存的数据。然后我启动一系列重复执行相同操作的命令。该应用程序预计会将大量多媒体数据加载到 RAM 中,然后下载。
不幸的是,图表并没有向我展示我所期望的。内存使用量通过 3 个不同的步骤增长,然后停止。内存显然从未释放,这暗示我存在巨大的内存泄漏。那会很好,因为这意味着我们很可能没有释放被媒体占用的内存。
但是在前三个步骤之后......内存使用稳定......没有任何更大的步骤......只是轻微的上下移动,对应于预期的数据加载和卸载。这里出乎意料的是,应该加载/卸载的数据占 RAM 的百分之一兆字节,而不是上升和下降仅占几兆字节(比如说 8-10 MB)。
我目前对解释这些数据一无所知。
有人有一些提示或建议吗?我错过了什么?我用来检查是否存在宏观内存泄漏的方法是否完全错误?你知道除了 Valgrind 之外的任何其他(最好是免费的)工具来检查内存泄漏吗?