我们有一个在 Linux 2.6.32 上运行的 posix 多线程 C++ 程序，它在其中一个线程中进行核心转储。使用gdb-7.2 corss-compiled分析核心文件，我们看到错误指令在这里
0x11491178 <+208>: lwz r0,8(r9)
并在框架显示中注册:
(gdb) info reg
r0 0x0 0
….
r9 0xdeaddead 3735936685
这是有道理的，因为 r9 在进程/线程的上下文中有一个无效的地址值(实际上是我们编写的堆清理模式)。
令人困惑的一点是r9是这样加载的
0x1149116c <+196>: lwz r9,0(r4)
和 r4 包含(第一个也是唯一的)函数参数“data”的值。 GDB 告诉我以下有关数据的信息:
(gdb) p data
$6 = (TextProcessorIF *) 0x4b3fe858
(gdb) p *data
$7 = {_vptr.TextProcessorIF = 0x128b5390}
(gdb) info symbol 0x128b5390
vtable for TextProcessorT<unsigned short> + 8 in section .rodata
在这种情况下，这一切都是正确的。所以 r9 应该有一个值 0x128b5390 而不是模式“0xdeaddead”，它是在内存空闲并返回堆时写入的。
那么，为什么当内存包含合法对象时寄存器 r9 包含清理后的值。我的理论是核心包含内存的快照，就像进程结束时一样，这是更远的实际崩溃发生时的行。在引发 SIGSEGV 后，堆内存的这个位置仍然可以被其他线程使用，因为它们正在记录数据，直到进程结束。因此，数据指向的内存可能已被再次分配并在内存快照被拍摄并保存在核心中时被使用/被使用。
我的问题是:
A) 我的理论正确吗？
B) 我假设堆内存快照不是在崩溃时(发出信号)而是在进程的最后时刻拍摄的，这是否正确？
C) 导致 SIGSEGV 的地址/位置仍然可以使用(由其他线程)？
谢谢!
最佳答案
您是否为 SIGSEGV 使用信号处理程序？它们是异步的和可重入的吗？
关于c++ - dumping Core 时 Heap snapshot 的时间，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24949876/