Стек вызовов 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>>

Я правильно настроил символы, теперь я хотел знать, как извлечь больше информации из стека вызовов.

  1. Журналы UMDH также имеют номера строк (с именами файлов) в своих логах diff. Однако в отчете DebugDiag я не вижу номеров строк этих функций. Если функции действительно очень длинные, тогда становится трудно описать контекст, просто просматривая стек вызовов без номеров строк. Есть ли способ извлечь номер строки функции (файла) из журналов DebugDiag?

  2. Еще одна вещь, которую я хотел знать, это значение шестнадцатеричного смещения с каждым module!function запись в стеки вызовов.

  3. Каков размер распределения в стеке вызовов? это выделенная память, которая не была освобождена (отсюда утечка) за выполнение этого стека вызовов?

  4. Любые указатели на исчерпывающую документацию о возможностях DebugDiag?

2

Решение

Журналы UMDH также имеют номера строк (с именами файлов) в своих логах diff. Однако в отчете об отладке я не вижу номеров строк этих функций.

Ну, тогда иди с логами UMDH.

значение шестнадцатеричного смещения с каждым module!function запись в стеки вызовов.

Шестнадцатеричное смещение указывает на конкретную инструкцию ассемблера в скомпилированном методе. Это примерно связано со смещением номера строки в исходном коде, но может сильно зависеть от оптимизации компилятора.

Каков размер распределения в стеке вызовов? это выделенная память, которая не была освобождена …

да

… за выполнение этого стека вызовов?

Нет. Запуск одного и того же метода снова может выделить другой размер. Рассмотрим функцию как AllocateSomeMemory(int bytes) это будет зависеть от параметра на то, сколько памяти выделено.

Любые указатели на исчерпывающую документацию о возможностях DebugDiag

Извините, я не могу упомянуть хороший сайт в моей голове.

0

Другие решения


По вопросам рекламы ammmcru@yandex.ru
Adblock
detector