Стек вызовов DebugDiag не отображает номер строки функций в стеке вызовов
Я пытаюсь изолировать утечки памяти в нативном коде на 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>>
Я правильно настроил символы, теперь я хотел знать, как извлечь больше информации из стека вызовов.
-
Журналы UMDH также имеют номера строк (с именами файлов) в своих логах diff. Однако в отчете DebugDiag я не вижу номеров строк этих функций. Если функции действительно очень длинные, тогда становится трудно описать контекст, просто просматривая стек вызовов без номеров строк. Есть ли способ извлечь номер строки функции (файла) из журналов DebugDiag?
-
Еще одна вещь, которую я хотел знать, это значение шестнадцатеричного смещения с каждым
module!functionзапись в стеки вызовов. -
Каков размер распределения в стеке вызовов? это выделенная память, которая не была освобождена (отсюда утечка) за выполнение этого стека вызовов?
-
Любые указатели на исчерпывающую документацию о возможностях DebugDiag?
Решение
Журналы UMDH также имеют номера строк (с именами файлов) в своих логах diff. Однако в отчете об отладке я не вижу номеров строк этих функций.
Ну, тогда иди с логами UMDH.
значение шестнадцатеричного смещения с каждым
module!functionзапись в стеки вызовов.
Шестнадцатеричное смещение указывает на конкретную инструкцию ассемблера в скомпилированном методе. Это примерно связано со смещением номера строки в исходном коде, но может сильно зависеть от оптимизации компилятора.
Каков размер распределения в стеке вызовов? это выделенная память, которая не была освобождена …
да
… за выполнение этого стека вызовов?
Нет. Запуск одного и того же метода снова может выделить другой размер. Рассмотрим функцию как AllocateSomeMemory(int bytes) это будет зависеть от параметра на то, сколько памяти выделено.
Любые указатели на исчерпывающую документацию о возможностях DebugDiag
Извините, я не могу упомянуть хороший сайт в моей голове.
Другие решения