我知道这不是一个新问题，但我在其他地方没有找到任何可行的方法。 我有一个 C 程序，它在运行时会不断消耗内存——我使用“free”命令来跟踪它，我可以看到只要它执行，可用内存量就会减少，这是不应该发生的。但是，我在程序本身中找不到任何可能导致这种情况的东西。我还用 valgrind 和 dmalloc 对其进行了测试，它们都能够检测到任何内存丢失。
如何找到泄漏点？
【问题讨论】：
标签： c debugging memory-leaks
如果您确定您的内存使用情况，那么问题可能不是您的 malloc 和 frees。
如果您使用任何库，您应该仔细检查您是否正确使用它们。许多具有初始化和释放功能，您很容易忘记，从而导致内存泄漏。
【讨论】：
内存真的泄漏了，还是程序运行的时间越长消耗的内存越多？换句话说，程序是否可能构建一个简单地继续增长的大型动态数据结构（链表等）？只要程序有一个指向内存的指针，它就不是真正的泄漏——但如果分配永远不会被释放，那么每个新的分配都会从操作系统获得更多的内存。这也可以解释为什么您使用的工具报告没有“泄漏”。
当我不得不这样做时，我会在每次我的程序分配内存并释放它时将日志消息写入平面文件。这些消息将包括诸如分配内存的文件名和程序行以及分配内存时从 malloc 返回的地址之类的内容，或者同样包括正在释放内存的文件名和程序行以及正在释放的缓冲区的地址。然后，您可以按地址对生成的文件进行排序，那些带有“ALLOCATE”消息但没有“FREE”消息的地址可能已经泄露——或者至少在程序终止时还没有释放。实施这可能会很耗时，如果您拥有自动化工具会更好 - 但根据您的情况，您可能必须执行此类操作。
或者，您可能只想使用垃圾收集器。 Boehm 收集器可能对您有用 - 看看 http://www.hpl.hp.com/personal/Hans_Boehm/gc/。
分享和享受。
【讨论】：
massif Valgrind 工具（而不是默认的memcheck），这是一个堆分析器。它将总分配的内存计入分配它的程序部分，这应该允许您查明正在使用内存的位置。
memcheck 工具。 Valgrind 实际上是几个不同工具的包，我建议改用massif 堆分析器（它不查找泄漏，但分析内存使用情况），基于它不是真正的“泄漏”的想法" 完全是经典意义上的。
(void)malloc(1000);（执行一次甚至有限次）不是内存泄漏，而在程序的生命周期内逐渐增加的内存使用量是内存泄漏，除非它与用户的特定需求相关联并且可以通过用户执行的某些操作来逆转。