Есть ли детектор утечки ручки, который может быть связан с существующим приложением? - PullRequest
6 голосов
/ 22 ноября 2011

Я участвую в различных проектах C ++ (в основном использующих MSVC6 вплоть до MSVC10), в которых мы недавно обнаружили несколько утечек дескрипторов (дескрипторы потоков, заданные функцией CreateThread).Я подозреваю, что есть и множество других дескрипторов, и я хотел бы интегрировать тест, который проверяет, что в наших результатах ночных тестов нет утечек.

Моя идея состояла в том, чтобы разработать DLL, инструментысоответствующие функции kernel32.dll (CreateThread, OpenProcess, CreateProcess и многие другие), а также функция CloseHandle.Затем DLL для каждого полученного дескриптора запоминает обратную трассировку.В конце процесса DLL распечатывает все обратные следы дескрипторов, которые не были закрыты для какого-либо файла журнала, который затем может быть проанализирован тестовой средой.

Это, конечно, также приведет к обратным следамдля всех дескрипторов, которые все еще доступны (так что технически они не просочились - возможно, автор предполагал, что ОС исправит их, когда процесс завершится), но я думаю, что их закрытие явно не повредит - тем более, что у нас уже есть некоторые хорошие RAII обертки для этого материала, мы просто не используем его так, как должны.

Теперь мне интересно - это кажется довольно простым подходом;может быть, кто-то здесь уже знает о библиотеке, которая уже делает это?

Ответы [ 5 ]

3 голосов
/ 22 ноября 2011

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

Думаю, проще всего было бы с Application Verifier. Вы можете получить его в Microsoft Средства отладки для Windows . Сконфигурируйте его для отслеживания дескрипторов вашего приложения, немного запустите ваше приложение в отладчике, и затем список дескрипторов будет сброшен при выходе из вашего приложения.

Еще один способ сделать это без Application Debugger - установить точку останова или паузу до выхода из приложения. Пока приложение приостановлено, используйте что-то вроде Process Explorer, чтобы получить список всех открытых дескрипторов.

Для ваших целей я думаю, что последний будет лучшим выбором. Я не уверен ни в каких автоматизированных инструментах, которые используют выходные данные отладки. Вы можете использовать некоторые функции WDK для получения списка открытых дескрипторов текущего процесса (или другого процесса), но это немного сложно.

2 голосов
/ 30 апреля 2012

Марк Руссинович объясняет в своей серии Расширение границ Windows , как лучше справляться с ручками и как отслеживать утечки ручек.

Он упоминает о WindowsОтладчик и Верификатор приложений, и он объясняет, как вы можете использовать это для отслеживания утечек вашего дескриптора.

На той же странице он упоминает также об опрятной функции его известного Process Explorer, который мигает зеленым икрасный для процессов, создающих / закрывающих дескрипторы.

1 голос
/ 04 мая 2012

Мы используем Memory Validator на моем текущем рабочем месте. Он может быть настроен для отслеживания каждого выделения памяти, вызова COM (и количества ссылок) и обработчиков. Вы запускаете его и либо запускаете код, необходимый для проверки, либо присоединяете к исполняемому коду, который хотите проверить. С этого момента он отслеживает любые ресурсы, которые вы сказали отслеживать. Когда код завершится, он получит отчет о любых отслеживаемых ресурсах, которые не были выделены, и о том, где они были распределены. Это коммерческий продукт, но у него есть пробный период, чтобы вы могли его протестировать и посмотреть, соответствует ли он вашим потребностям. Это было несколько полезно для меня и коллег, когда у нас были неприятные утечки в сложных ситуациях, но это не волшебное решение для себя. Хорошие методы поиска утечек все еще необходимы, они просто дают вам дополнительную информацию о том, какие ассигнования все еще существуют и откуда они взялись.

1 голос
/ 01 мая 2012

Если вы прочитали статью «Pushing the Limits of Windows», то увидели бы, что в ней упоминается расширение WinDbg! Htrace, которое, я думаю, соответствует вашему первому требованию для инструментирования соответствующих функций kernel32.dll, связанных с созданием дескрипторов.

Чтобы автоматизировать вызов! Htrace, вы можете встроить механизм отладчика в свой тестовый комплект или использовать что-то вроде PyDbgEng , чтобы запустить ваше приложение и вызвать расширение! Htrace, а затем собратьстеки, когда приложение заканчивается.Есть пример этого типа автоматизации с PyDbgEng, но с функциями реестра на http://pydbgeng.svn.sourceforge.net/viewvc/pydbgeng/trunk/PyDbgEng/Examples/RegMon.py?view=markup, но я думаю, что вы могли бы использовать этот пример для вызова расширения, см. (Dbg.idebug_control.CallExtension) в примере.

0 голосов
/ 21 июля 2015

Я играл с Deleaker и имел успех с утечками памяти и обработкой.Он может быть использован в Visual Studio или самостоятельно.С веб-сайта Deleaker:

Неважно, какой тип утечек произошел, Deleaker находит их все: утечки памяти (вызванные кучей, виртуальной памятью или распределителями OLE и т. Д.), Утечки GDIутечки объектов Windows USER и дескрипторов . "

...