2

我正在尝试使用普通页面堆（未满）测试崩溃场景（在隔离的测试应用程序中）。

我已经设置了标志

gflags /p /enable Test.exe

我正在用一个元素覆盖一个整数缓冲区

...
const size_t s = 100;
vector<int> v1(s, 0);
int* v1_base = &v1[0];
write_to_memory_int(v1_base, s+1);
...

事实上，当向量 d'tor 中的块被释放时，我得到了休息。正确报告了中断的调用堆栈：

0:005> kp
  *** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr  
0785faa4 11229df2 verifier!VerifierStopMessage+0x1f8
0785fb08 1122a22a verifier!AVrfpDphReportCorruptedBlock+0x1c2
0785fb64 1122a742 verifier!AVrfpDphCheckNormalHeapBlock+0x11a
0785fb84 112290d3 verifier!AVrfpDphNormalHeapFree+0x22
0785fba8 77951564 verifier!AVrfDebugPageHeapFree+0xe3
0785fbf0 7790ac29 ntdll!RtlDebugFreeHeap+0x2f
0785fce4 778b34a2 ntdll!RtlpFreeHeap+0x5d
0785fd04 750c14dd ntdll!RtlFreeHeap+0x142
0785fd18 71fc4c39 kernel32!HeapFree+0x14
0785fd64 00404b0a msvcr80!free(void * pBlock = 0x0726f7b8)+0xcd [f:\dd\vctools\crt_bld\self_x86\crt\src\free.c @ 110]
0785fd90 00402ac7 Test!std::vector<int,std::allocator<int> >::_Tidy
...

但是，当我查看错误分配时，我只得到：

0:005> !heap -p -a 0x0726f7b8
    address 0726f7b8 found in
    _HEAP @ 30000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        0726f790 0039 0000  [00]   0726f7b8    00190 - (busy)
        1122a6a7 verifier!AVrfpDphNormalHeapAllocate+0x000000d7
        11228f6e verifier!AVrfDebugPageHeapAllocate+0x0000030e
        77950d96 ntdll!RtlDebugAllocateHeap+0x00000030
        7790af0d ntdll!RtlpAllocateHeap+0x000000c4
        778b3cfe ntdll!RtlAllocateHeap+0x0000023a

也就是说，有一个分配堆栈跟踪，但它停止在RtlAllocateHeap这显然完全没用。

查看内存中的堆栈跟踪：

dt _DPH_BLOCK_INFORMATION ....-0x20

=>

0:005> dds 0x03e556f4
03e556f4  00000000
03e556f8  00002050
03e556fc  00050000
03e55700  1122a6a7 verifier!AVrfpDphNormalHeapAllocate+0xd7
03e55704  11228f6e verifier!AVrfDebugPageHeapAllocate+0x30e
03e55708  77950d96 ntdll!RtlDebugAllocateHeap+0x30
03e5570c  7790af0d ntdll!RtlpAllocateHeap+0xc4
03e55710  778b3cfe ntdll!RtlAllocateHeap+0x23a
03e55714  00000000
03e55718  00003001
03e5571c  0004005e

看来实际上没有更多的记录了。

如何修复页面堆以记录有用的堆栈跟踪？

请注意，Test 项目不是使用 FPO (/Oy) 编译的，我没想到RtlAllocateHeap会受到 FPO 的影响？

更新：我通过手动进入分配检查了相关调用的 FPO 特性（见下文），看起来VC80（VS2005）运行时库malloc和op newVC80（VS2005）运行时库都启用了某种形式的 FPO ......所以也许这弄乱了页堆的堆栈数据库的堆栈跟踪。

0:004> kv
ChildEBP RetAddr  Args to Child              
077efa7c 77c8af0d 05290000 01001002 00000190 ntdll!RtlDebugAllocateHeap+0x16 (FPO: [Non-Fpo])
077efb60 77c33cfe 00000190 00000000 00000000 ntdll!RtlpAllocateHeap+0xc4 (FPO: [Non-Fpo])
077efbe4 72344d83 05290000 01001002 00000190 ntdll!RtlAllocateHeap+0x23a (FPO: [Non-Fpo])
077efc04 62f595ee 00000190 00000000 00000000 MSVCR80!malloc+0x7a (FPO: [1,0,0]) (CONV: cdecl) 
077efc1c 00406a44 00000190 ebecf74f 00000001 MFC80U!operator new+0x2f (FPO: [Uses EBP] [1,0,0]) (CONV: cdecl)
077efc48 00405479 00000064 00000000 3fffffff Test!std::_Allocate<ATL::CStringT<wchar_t,StrTraitMFC_DLL<wchar_t,ATL::ChTraitsCRT<wchar_t> > > >+0x84 (FPO: [Non-Fpo]) (CONV: cdecl)
077efcb8 004049f4 00000064 ebecf68f 00000000 Test!std::vector<unsigned int,std::allocator<unsigned int> >::_Buy+0x69 (FPO: [Non-Fpo]) (CONV: thiscall)
077efd88 00402a4f 00000064 077efdc0 ebecf44b Test!std::vector<int,std::allocator<int> >::_Construct_n+0x44 (FPO: [Non-Fpo]) (CONV: thiscall)
077eff4c 72342848 00000000 ebec8474 00000000 Test!crashFN+0x35f (FPO: [Non-Fpo]) (CONV: cdecl) 
077eff84 723428c8 75da33aa 072ab3d8 077effd4 MSVCR80!_callthreadstart+0x1b (FPO: [Non-Fpo]) (CONV: cdecl)
077eff88 75da33aa 072ab3d8 077effd4 77c39f72 MSVCR80!_threadstart+0x5a (FPO: [1,0,0]) (CONV: stdcall)
077eff94 77c39f72 072ab3d8 70fca8b2 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [Non-Fpo])
077effd4 77c39f45 7234286e 072ab3d8 00000000 ntdll!__RtlUserThreadStart+0x70 (FPO: [Non-Fpo])
077effec 00000000 7234286e 072ab3d8 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])
4

1 回答 1

2

感谢@Marc Sherman 在评论中指出我应该查看真正的分配堆栈跟踪。

正如已经在问题中编辑的那样，VC80(VS2005) 是这里的问题，因为它的 CRT 启用了 FPO，如堆栈跟踪所示：

MSVCR80!malloc+0x7a (FPO: [1,0,0]) (CONV: cdecl) 
MFC80U!operator new+0x2f (FPO: [Uses EBP] [1,0,0]) (CONV: cdecl)

现在，有了要搜索的锚点，我们发现以下内容：

为什么 UMDH 中的每个堆跟踪都卡在“malloc”？

添加几个引号：

特别是，Visual C++ 2005 上静态链接 CRT 上的默认 malloc 实现似乎不仅不使用帧指针，而且将 ebp 作为临时寄存器丢弃......

这是什么意思呢？嗯，任何使用用 Visual C++ 2005 构建的 malloc 的东西都不能用 UMDH 或任何其他依赖于基于 ebp 的堆栈跟踪的东西来诊断，至少在 x86 版本上是这样。

评论中也有回复，有很好的信息：

马克·罗伯茨 [MSFT] 说：2008 年 2 月 25 日下午 3:03

你好，

为 8.0 CRT 启用 FPO 并不是故意的。Visual Studio 2008 CRT (9.0) 没有启用 FPO，UMDH 应该可以正常工作。

对于 8.0，UMDH 的替代方法是使用 LeakDiag。LeakDiag 实际上会检测内存分配器以获取堆栈跟踪。这使得它比 UMDH 更通用，因为它可以以不同的粒度挂钩几种不同的分配器类型（从 c 运行时到原始虚拟内存分配）。

默认情况下，LeakDiag 只是遍历堆栈基指针，但可以对其进行修改以使用 Dbghlp StackWalkAPI 来解析 FPO 数据。这将产生完整的堆栈，尽管性能损失更高。另一方面，您可以自定义堆栈行走行为以仅进入某个深度等，以最大限度地减少性能损失。

请在此处找到 LeakDiag：ftp: //ftp.microsoft.com/PSS/Tools/Developer%20Support%20Tools/LeakDiag/leakdiag125.msi

于 2013-09-27T13:56:07.577 回答