在gdb中进行内存分配

Question

当我逐步调试gdb调试器中的程序时，为什么内存消耗会无法预测？我正在尝试使用gdb来找出为什么一个程序使用的内存远远超过它应该的内存，并且它不合作。

我在监视进程内存使用情况时单步执行源代码，但由于两个原因，我无法找到分配内存的行：

1. 报告的内存使用量仅以（通常但不总是精确）64 MB的增量跳转。我怀疑我看到一些内存管理器的影响，我不知道哪一个预留64 MB，并掩盖了多个较小的分配。
2. 跳转不会发生在代码中的一致位置。它不仅在不同的gdb运行期间出现在不同的行上;它有时也会发生在不合逻辑的地方，比如（c ++）函数的右括号。 gdb本身是否可能影响内存分配？

有关更有效工具的任何想法/建议，以帮助我深入了解真正负责这些内存分配的代码行吗？

以下是一些相关的系统信息：我在Windows下的虚拟CentOS Linux机器上运行x86_64-redhat-linux-gnu版本7.2-64.el6-5.2。该程序是通过一个复杂的构建脚本构建在远程服务器上的，所以在任何一点上确切地追踪使用的选项本身就是一件苦差事。我正在使用top实用程序（“virt”或虚拟内存列）监视内存使用情况，并通过读取实时监控文件/proc/<pid>/status，他们同意。由于此程序使用大量的第三方库，因此可能会涉及一个或多个被覆盖的malloc()函数，这些函数我不知道 - 搜索它们是此任务的一部分。

Answer 1

gdb（留给自己的设备）不会影响程序的内存使用，尽管gdb下的运行可能因独立运行而有所不同。

但是，这还取决于您使用gdb的方式。如果你只是设置简单的断点，踩踏和打印东西，那么你没问题。但有时，为了评估表达式，gdb将在下级中分配内存。例如，如果您有像strcmp(arg, "string") == 0这样的断点条件，那么gdb将为该字符串常量分配内存。还有其他类似的情况。

Answer 2

这个答案分为几部分，因为有几件事情在进行：

1. 使用Massif模块（内存分析器）的Valgrind对此问题比\1更有帮助。有时使用调试器快速查看，有时则不然。 http://valgrind.org/docs/manual/ms-manual.html
2. gdb是一个用于分析内存使用情况的糟糕工具，因为它只报告虚拟内存分配，在这种情况下，它是实际堆内存使用量的3倍。当进程请求内存块时，Unix内核会映射虚拟内存并使其可用，但不一定使用它。底层系统调用是top。我还是不知道如何检查块大小。 mmap()只能告诉你Unix内核对你的内存消耗的了解，这不足以提供帮助。不要使用它（或/ proc /下的内存文件）进行详细的内存分析。
3. 退出函数时的内存分配是由autolocks引起的 - 这是一个线程锁类，当析构函数超出范围时，析构函数会释放锁。然后一个不同的线程开始行动并分配一些内存，让操作员（我）神秘化。不可重复性可能是因为某些线程正在等待Internet连接等外部资源。