Почему malloc / new перехватывает стек вызовов?
У меня есть 64-битное приложение, которое работает в качестве службы под Server 2003.
Когда я присоединяю VS Profiler или windbg, я вижу множество стеков вызовов, как показано ниже. Я понимаю, что процессы, порожденные в отладчике (или профилировщике), используют кучу отладки и т.д. … Но это не тот случай, так как эта служба запускается операционной системой, и я только присоединяюсь к ней.
Я не понимаю, почему это раскручивает стек. И профилировщик показывает, что на это уходит значительное количество времени. Еще немного информации:
• Это биты выпуска, созданные с помощью vc9, работающие на Server 2003.
• Системная переменная среды _NO_DEBUG_HEAP установлена в 1.
• Я использую серверы символов Microsoft.
Почему он захватывает трассировку стека? Кажется, это регистрируется … но я не могу найти где.
Моя цель — убедиться, что приложение действительно раскручивает стек и, если это правда, постараться избежать этого.
Есть идеи?
ntdll!RtlVirtualUnwind
ntdll!RtlpWalkFrameChain
ntdll!RtlCaptureStackBackTrace
ntdll!RtlpCaptureStackTraceForLogging
ntdll!RtlLogStackBackTrace
ntdll!RtlDebugAllocateHeap
ntdll!RtlAllocateHeapSlowly
ntdll!RtlAllocateHeap
MSVCR90!malloc
MSVCR90!operator new
Решение
Возможно, кто-то использовал Gflags.exe для включения захвата трассировки стека пользователей для этого процесса или для всей системы, или для какого-либо другого флага, который требует отслеживания операций выделения CRT.
Вы должны быть в состоянии проверить эту возможность в реестре, используя информацию Вот.
Другие решения
Ответ Стива великолепен и, в конечном счете, привел к решению для нашего собственного сервера после долгого расследования. Наша ситуация была несколько иной, и причиной захвата стека была сценарий, периодически запускающий захват UMDH. UMDH включит сбор стека при первом выполнении этого процесса. Это дает следующее предупреждение:
UMDH has enabled allocation stack collection for the current running process.