2

我正在尝试隔离 Windows 上本机代码中的内存泄漏。

我运行了测试用例的多次迭代并将 DebugDiag 附加到进程以收集有关可疑泄漏的信息(通过 PerfMon 中的多次运行确认内存泄漏)。

DebugDiag 指出了可疑的调用堆栈,例如

 Call stack sample 1

 Address   0x0f09e2c0

 Allocation Time   00:22:38 since tracking started 

 Allocation Size   8.54 KBytes 

    Function                                       Source destination
    ntdll!RtlpReAllocateHeap+19c                  ntdll!RtlAllocateHeap 
    ntdll!_except_handler4       
    ntdll!RtlReAllocateHeap+22f                   ntdll!RtlReAllocateHeap 
    sqlncli11!MpReallocZeroMemory+66     
    sqlncli11!SQLReAllocateMemoryEx+22            sqlncli11!MpReallocZeroMemory 
    sqlncli11!AllocPlex+1a4                       sqlncli11!SQLReAllocateMemoryEx 
    sqlncli11!SetADRec+2a4                        sqlncli11!AllocPlex 
    sqlncli11!SQLBindCol+217                      sqlncli11!SetADRec 
    odbc32!SQLBindCol+3c0       
    sscfdm!CSSLockSqlCursor::DoExecuteStmt+11a       
    sscfdm!CSSSqlCursor::Execute+129              sscfdm!CSSLockSqlCursor::DoExecuteStmt 
    sscfdm!CSSSqlObj::Execute+d86                 sscfdm!CSSSqlCursor::Execute 
    sscfom!CSSBusComp::SqlExecute+3a              sscfdm!CSSSqlObj::Execute 
    <<many multiple lines below>>

我已经正确配置了符号,现在我想知道如何从调用堆栈中提取更多信息。

  1. UMDH 日志在其差异日志中也有行号(带有文件名)。但是在 DebugDiag 报告中,我没有找到这些函数的任何行号。如果函数真的很长,那么仅通过查看调用堆栈而没有行号就很难描述上下文。有什么方法可以从 DebugDiag 日志中提取函数(文件)的行号?

  2. 我想知道的另一件事是module!function调用堆栈中每个条目的十六进制偏移量的重要性。

  3. 调用堆栈中的分配大小是多少?是每次执行此调用堆栈时尚未释放(因此泄漏)的分配内存吗?

  4. 有关 DebugDiag 功能的综合文档的任何指针?

4

1 回答 1

0

UMDH 日志在其差异日志中也有行号(带有文件名)。但是在调试诊断报告中,我没有找到这些函数的任何行号。

好吧,然后使用 UMDH 日志。

module!function调用堆栈中每个条目的十六进制偏移量的重要性。

十六进制偏移量指向编译方法中的特定汇编程序指令。它与源代码中的行号偏移量大致相关,但可能会受到编译器优化的严重影响。

调用堆栈中的分配大小是多少?是不是分配的内存没有被释放...

是的

...每次执行此调用堆栈?

不可以。再次运行相同的方法可能会分配不同的大小。考虑这样的函数AllocateSomeMemory(int bytes)将取决于分配多少内存的参数。

任何指向有关 DebugDiag 功能的综合文档的指针

抱歉,我无法在脑海中提及一个好的网站。

于 2015-09-17T22:00:08.543 回答