Я провел последнюю неделю, работая над инструментом поиска утечек GDI. Мы также проводим регулярное стресс-тестирование, и оно никогда не длилось дольше, чем стоимость дня без остановки из-за чрезмерного потребления дескриптора объекта user / gdi.
Насколько я могу судить, мои попытки были довольно успешными. Конечно, я заранее потратил некоторое время на поиски альтернативного и более быстрого решения. Стоит отметить, что у меня был некоторый предыдущий полу-везучий опыт работы с инструментом GDILeaks из статьи msdn, упомянутой выше. Не говоря уже о том, что мне пришлось решить несколько проблем, прежде чем приступить к работе, и на этот раз мне просто не дали того, что и как я хотел. Недостатком их подхода является тяжелый интерфейс отладчика (он на несколько порядков замедляет исследуемую цель, что я считаю недопустимым). Другим недостатком является то, что он не работал все время - на некоторых прогонах я просто не мог заставить его сообщать / вычислять что-либо! Его сложность (судя по количеству кода) была еще одним фактором отпугивания. Я не большой поклонник графических интерфейсов, так как я считаю, что я более продуктивен без окон вообще; о). Мне также было трудно заставить его находить и использовать мои символы.
Еще один инструмент, который я использовал перед настройкой для написания своего собственного, был leakbrowser .
В любом случае, я наконец остановился на итеративном подходе для достижения следующих целей:
- незначительные штрафы за исполнение
- Простота реализации
- неинвазивность (используется для нескольких продуктов)
- полагается на максимально возможное количество
Я использовал обходные пути (некоммерческое использование) для основной функциональности (это инъекционная DLL). Включите использование Javascript для автоматической генерации кода (от 15K сценария до исходного кода 100K поколения - я никак не могу кодировать это вручную и без препроцессора C!), А также расширение windbg для анализа данных и поддержки снимков / различий.
Короче говоря, после того, как я закончил, мне потребовалось несколько часов для сбора информации во время другого стресс-теста и еще один час для анализа и устранения утечек.
Я буду более чем рад поделиться своими выводами.
P.S. Некоторое время я потратил на попытки улучшить предыдущую работу. Моим намерением было свести к минимуму ложные срабатывания (я видел слишком много таких при разработке), поэтому он также будет проверять согласованность распределения / выпуска, а также избегать учета распределений, которые никогда не просочились.
Редактировать: Найти инструмент здесь