我正在调试转储文件,而我可以访问符号文件。
我正在使用一个脚本,它结合了以下windbg
命令的结果:
x /2 *!* // which types are present in the symbol files?
!heap -h 0 // which memory address ranges are used in the dump?
(至少,这就是我的理解。如果我错了,请不要犹豫,纠正我)
在this list of Windbg extensions下找到的脚本(名为heap_stat.py
)的结果是内存地址列表,后跟其类型。如果存在内存泄漏,可以通过统计我可以得到的数据。
除此之外,使用所提到的内存地址的WinDbg命令dt CStringArray m_nSize
(当然在CStringArray
的特定情况下),我可以看到使用的条目总数CStringArray
个对象,查看是否有CStringArray
个包含大量条目的对象。
然而,该系统存在缺点:
当我发现这样一个带有大量条目的CStringArray
对象时,我被困在那里,因为在我的应用程序中的所有CStringArray
对象中,我不知道我正在处理哪一个。 / p>
可能有帮助的一件事是内存地址所涉及的局部变量的名称,但是有一个问题:我不知道这些信息是否存在,如果是,我可以在符号文件中找到它还是在转储中,(显然)我需要运行哪个命令才能获取此信息(我没有找到使dt <flag> <memory address>
返回由<memory address>
占用的本地变量名称的标志?
有人能帮助我吗?
为了澄清,这是我的脚本目前的结果:
0x0065a4d0 mfc110u!CStringArray Size:[1]
0x0065a4e4 mfc110u!CStringArray Size:[0]
0x0065a4f8 mfc110u!CStringArray Size:[295926]
0x0065a520 mfc110u!CStringArray Size:[0]
如您所见,我可以看到存储变量的内存地址,我可以看到类型(从符号文件中检索),我可以看到条目数量(从dt
检索到Windbg
命令),但我希望得到如下输出:
0x0065a4d0 mfc110u!CStringArray Size:[1] var1
0x0065a4e4 mfc110u!CStringArray Size:[0] var2
0x0065a4f8 mfc110u!CStringArray Size:[295926] var3
0x0065a520 mfc110u!CStringArray Size:[0] var3
或:
0x0065a4d0 mfc110u!CStringArray Size:[1] obj1.prop1
0x0065a4e4 mfc110u!CStringArray Size:[0] obj2.prop1
0x0065a4f8 mfc110u!CStringArray Size:[295926] obj1.prop2
0x0065a520 mfc110u!CStringArray Size:[0] obj1.prop2
此类输出表明我需要验证源代码中var3
或obj1.prop2
的内容。
答案 0 :(得分:1)
我写了以下MFC应用程序(部分源代码):
CStringArray stringarray;
void* anotherarray = new CStringArray();
void CLocalVariableNameApp::AnotherMethod(void* a)
{
CStringArray* temp = static_cast<CStringArray*>(a);
temp->Add(L"Something else");
}
CLocalVariableNameApp::CLocalVariableNameApp()
{
stringarray.Add(L"Something");
AnotherMethod(anotherarray);
CStringArray* holycow = static_cast<CStringArray*>(anotherarray);
holycow->Add(L"Yet something else");
DebugBreak();
}
如您所见,第二个CStringArray有多个名称:anotherarray
,a
,temp
和holycow
。
观察1:内存地址和变量名称不会有简单的1:1映射。
PDB文件中提供了本地变量名称:
0:000> k
# ChildEBP RetAddr
00 0022fa40 00fa2a30 KERNELBASE!DebugBreak+0x2
01 0022fb3c 00f97958 LocalVariableName!CLocalVariableNameApp::CLocalVariableNameApp+0x90 [c:\...\localvariablename.cpp @ 38]
02 0022fc10 014b628a LocalVariableName!`dynamic initializer for 'theApp''+0x28 [c:\...\localvariablename.cpp @ 43]
03 0022fc18 014b5e8c LocalVariableName!_initterm+0x1a [f:\...\crt0dat.c @ 955]
04 0022fc2c 014a9263 LocalVariableName!_cinit+0x6c [f:\...\crt0dat.c @ 308]
05 0022fc78 014a947d LocalVariableName!__tmainCRTStartup+0xf3 [f:\...\crt0.c @ 237]
06 0022fc80 7558336a LocalVariableName!wWinMainCRTStartup+0xd [f:\...\crt0.c @ 165]
07 0022fc8c 771198f2 kernel32!BaseThreadInitThunk+0xe
08 0022fccc 771198c5 ntdll!__RtlUserThreadStart+0x70
09 0022fce4 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000> .frame 1
01 0022fb3c 00f97958 LocalVariableName!CLocalVariableNameApp::CLocalVariableNameApp+0x90 [c:\...\localvariablename.cpp @ 38]
0:000> dv
this = 0x01637118
holycow = 0x00445820
请注意,名称a
和temp
不可见。
观察2:变量名称将限于其范围。如果要记住所有变量名称,则需要跟踪所有函数。
上面是调试版本。发布版本不同:
0:000> k
# ChildEBP RetAddr
00 005efe04 002a1c18 KERNELBASE!DebugBreak+0x2
01 005efe20 002a1095 LocalVariableName!CLocalVariableNameApp::CLocalVariableNameApp+0x88 [c:\...\localvariablename.cpp @ 39]
02 005efe24 003c0289 LocalVariableName!`dynamic initializer for 'theApp''+0x5 [c:\...\localvariablename.cpp @ 43]
03 005efe38 003c01ea LocalVariableName!_initterm+0x29 [f:\...\crt0dat.c @ 954]
04 005efe48 003bd280 LocalVariableName!_cinit+0x5a [f:\...\crt0dat.c @ 321]
05 005efe88 7558336a LocalVariableName!__tmainCRTStartup+0xde [f:\...\crt0.c @ 237]
06 005efe94 771198f2 kernel32!BaseThreadInitThunk+0xe
07 005efed4 771198c5 ntdll!__RtlUserThreadStart+0x70
08 005efeec 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000> .frame 1
01 005efe20 002a1095 LocalVariableName!CLocalVariableNameApp::CLocalVariableNameApp+0x88 [c:\...\localvariablename.cpp @ 39]
0:000> dv
this = 0x0043f420
请注意,holycow
缺失。
观察3:在发布版本中,可能不需要(优化)变量,因此不存在。
总体结论:无法将内存地址映射到变量名称。