Отладка приложений


Куда направляются отчеты об утечках памяти? - часть 2


Надо всегда работать с этой библиотекой, какими бы дополнительными инструментами отладки вы ни пользовались.

Поскольку директива #pragma init_seg(compiler) уже использовалась для предварительной инициализации класса AutoMatic (и вызова деструктора после выполнения самого последнего оператора приложения), то в этой же точке исходного кода нужно было выполнять и проверку утечки памяти, а затем выключать флажок _CRTDBG_LEAK_CHECK_DF, чтобы DCRT-библиотека не выводила собственных отчетов. Единственное предостережение — при использовании этого подхода необходимо удостовериться, что выбранная CRT-библиотека включается перед файлом BUGSLAYERUTIL.LIB (если компоновка выполняется с ключом /NODEFAULTLIB). При компоновке файла BUGSLAYERUTIL.LIB может оказаться, что CRT-библиотеки не зависят от соответствующих директив #pragma init_seg(compiler), гарантирующих, что данные этих библиотек инициализируются первыми, а разрушаются последними, так что поддерживать правильный порядок в размещении этих директив программист должен самостоятельно.

Здесь речь идет о размещении указанной директивы перед исходным кодом отлаживаемого приложения. — Пер.

Если внимательно подумать, то установка режима чистки обработчиков функций вывода дампов DCRT-библиотекой имеет определенный смысл. Если бы ваш обработчик использовал какую-нибудь функцию из CRT-библиотеки (скажем, printf), то он мог бы завершить вашу программу аварийно, потому что, когда вызывается функция _crtDumpMemoryLeaks, CRT-библиотека находится где-то в середине процесса завершения своей работы. Надо соблюдать правила и всегда компоновать DCRT-библиотеку перед компоновкой любых других библиотек, т. к. функции расширения MemDumperValidator завершаются прежде, чем заканчивает работу DCRT-библиотека. Чтобы обойти подобные проблемы, применяйте в дамп-функциях только макросы _RPTn и _RPTFH, потому что их использует и функция _CrtDumpMemoryLeaks.

 




Начало  Назад  Вперед



Книжный магазин