我有一个内存泄漏应用程序的核心转储。 我已经使用了string命令和xdd来检查文件，并且我已经知道程序的哪一部分可能是泄漏的原因。 我可以在应用程序中运行gdb中的核心文件，但是我不能做很多的testing，因为它是一个embedded式应用程序，有很多复杂的基于时间的I / O，我不能在办公室里模拟。
我也听说用各种内存泄漏检测工具运行会减慢我们无法承受的应用程序，因为它已经在CPU容量附近运行了。
所以现在，我拥有的就是这个核心文件。 我正在寻找的例子：有没有一个指针表，我可以检查，find已分配的内存，然后我可以用来尝试find本应该被释放，但没有？
不是很容易，不。 泄漏的内存的全部重点是分配的内存不再被引用。
你将不得不遍历整个内存区域来获取所有已分配块的列表，然后检查可能指向它的每个可能的变量/内存位置（几乎肯定有一些误报）。
这可能是值得一枪获得一些统计分配的块。 假设你的内存泄漏导致了内存不足的问题， 大部分的块将是一个特定的类型，根据可能的大小或内容。
例如，如果80％的分配块长度为31424字节，那么您将在寻找该范围的分配（根据内存分配器的工作原理，给出或占用16个字节）。
或者，如果它们都包含“2011-01-01 15:25:00开始进程42”之类的字符串，则可能需要在日志记录库中查找泄漏。
无论如何，您将不得不深入到C ++运行时源代码中来找出如何找到内存领域，然后使用该代码来遍历结构。
内存泄漏可以通过paxdiablo给出的核心转储进行评估。 另外，如果在corefile中重复一些模式，那么它可以评估如下：1.我已经采取了一个示例c + +的例子：
class Base { public: virtual void fun(){} virtual void xyz(){} virtual void lmv(){} virtual void abc(){} }; class Derived: public Base { public: void fun(){} void xyz(){} void lmv(){} void abc(){} }; void fun() { Base *obj = new Derived(); } int main() { for(int i=0; i<2500;i++) fun(); sleep(3600); return 0; } 用gcore命令创建一个核心
从核心文件中搜索重复的模式。 ayadav @ ajay-PC：〜$ hexdump core.10639 | awk'{printf'％s％s％s％s \ n％s％s％s％s \ n“，$ 5，$ 4，$ 3，$ 2，$ 9，$ 8，$ 7，$ 6} 排序| uniq -c | sort -nr | 头66850000000000000000
2502 0000002100000000
2500 004008d000000000
726 0000000000007eff
502
125 2e4314d000007eff
93 006010d000000000
81 0000000100007eff
80 0000000100000000
73 0000000000000001
0000002100000000和004008d000000000是重复模式
检查每个qword是什么？ （gdb）info symbol …（gdb）x …
例
（gdb）信息符号0x4008d000
没有符号匹配0x4008d000。
（gdb）信息符号0x4008d0
/ home / ayadav / virtual部分.rodata中的派生+ 16的vtable
可能最频繁的vtable必须涉及内存泄漏，即派生的vtable。
注：我同意coredump分析是不是找到内存泄漏的最佳实践。 内存泄漏可以使用不同的静态和动态工具，如valgrind等
正如paxdiablo所说，通过查看堆（malloc）数据结构验尸后发现泄漏的内容几乎是不可行的。
找出哪种类型的对象泄漏的一个相当轻的方法是为每个可能泄漏的类设置一个实例计数器。 这样你就可以检查核心文件中的实例计数器。