我有一个问题是出于对检查内存泄漏的好奇心。
作为一个经常使用valgrind来检查我的代码在过去一两年中是否存在内存泄漏的人，我突然想到它只能在程序生命周期后检测到丢失/不一致的内存。
因此，鉴于此，我想如果你有一个长期运行的程序，malloc()间歇性地并且在应用程序退出之前不会free()，那么吃内存的可能性（不一定是通过泄漏）是巨大的，不是使用这些工具可观察，因为它们只在程序生命周期后检查。是否有类似GDB的工具可以在运行时停止应用程序并检查应用程序生命周期中某个实例是否存在的内存？
是否有类似GDB的工具可以在运行时停止应用程序并检查应用程序生命周期中某个实例是否存在的内存？
是的：Valgrind。
具体来说，Valgrind的SVN版本中嵌入了一个gdbserver存根。
这允许您进行各种很酷的调试，之前不可能：
我想你也可以要求它列出未泄漏的新分配。
在支持指针运算的语言中通常不可能这样做，因为例如 - 您可以将指针转换为整数并返回。见http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/BitOp/pointer.html
对于长时间运行的基于套接字的服务器，我所做的，不是工具，是做一个操作，但在打印出可用内存量之前，然后在我的操作后打印出来，看看是否有有什么区别。
我知道理论上我的服务器应该已经返回了每次调用服务器时使用的所有内存，所以如果我是唯一一个调用它的人，它应该不会比启动时使用更多的内存。
您可能会发现第一次调用时需要一些内存，因此您可能需要进行多次调用，因此所有内容都已初始化，然后您可以执行此类检查。
另一个选项是创建一个列表，其中包含您正在进行mallocing的所有内存，然后当您释放它时，从列表中删除该节点，最后查看哪些内存仍未被释放。
泄漏的内存定义为程序中任何内容都未引用的内存。
如果你对内存和数据中的某个地方进行了malloced，那么就会有一个指向该内存的指针，就任何自动检查而言，它都不会“丢失”。
但是，如果你分配了内存，永远不会释放它，但你没有指向它的任何指针，你很可能泄露了那个内存 - 因为你无法引用它。
像valgrind这样的程序可以找到上述类型的泄漏（丢失参考）。 AFAIK没有任何东西可以找到“逻辑”泄漏，你仍然持有对内存的引用。