Можете ли вы запускать и останавливать Boundschecker (DevPartner)?

Question

Я пытаюсь использовать Boundschecker для анализа довольно сложной программы.Запуск программы с помощью Boundschecker почти слишком медленный, чтобы от нее можно было получить какую-либо пользу, поскольку мне требуется почти день, чтобы запустить программу до того места в коде, где я подозреваю, что проблема существует.Может ли кто-нибудь дать мне несколько идей о том, как проверять только определенные части моего программного обеспечения с помощью Boundschecker (DevPartner) в Visual Studio 2005?

Заранее спасибо за вашу помощь!

Answer 1

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

Но нам все равно нужна была некоторая функциональность, но, как и вам, не для всей программы.Поэтому нам пришлось сделать это самим.

В нашем случае мы в основном использовали его для отслеживания утечек памяти.Если это и ваша цель, есть и другие варианты.

1. Visual Studio довольно хорошо сообщает вам об утечках памяти при выходе из программы.
2. Он сообщает об утечках в том порядке, в котором они были созданы.
3. Он сообщит вам, где именно была создана утечка памяти, если в исходных файлах это указано вверху.

#ifdef _DEBUG
#undef THIS_FILE
static char THIS_FILE[]=__FILE__;
#define new DEBUG_NEW
#endif

Они очень помогают, но зачастую этого недостаточно.Добавление этого фрагмента повсюду не всегда возможно.Если вы используете фабричные классы, знание того, где была выделена память, совершенно не поможет.Поэтому, когда все остальное терпит неудачу, мы воспользуемся преимуществом №2.

Добавьте что-то вроде следующего:

#define LEAK(str) {char *s = (char*)malloc(100); strcpy(s, str);}

Затем перемешайте свой код "утечка (" утечка1 ");" или что -то еще.Запустите программу и выйдите из нее.Ваши новые просочившиеся строки будут отображаться в дампе утечек Visual Studio вокруг существующих утечек.Продолжайте добавлять/перемещать утверждения LEAK и перезапускать программу, чтобы сузить область поиска, пока не определите точное местоположение.Затем устраните утечку, удалите утечки отладки, и все готово!

Answer 2

BoundsChecker отслеживает все выделения памяти и освобождает в мельчайших подробностях. Он знает, например, что такое-то выделение памяти было сделано из кучи времени выполнения C, которая, в свою очередь, была взята из кучи Win32, которая, в свою очередь, начала жизнь как память, выделенная VirtualAlloc. Если приложение инструментировано (FinalCheck), оно также содержит подробную информацию о том, какие указатели ссылаются на память.

Это одна из причин (многих), почему дело идет медленно.

Если бы BC подключился к приложению с опозданием, у него не было бы ни одной из этих собранных данных, и он либо (1) выкопал бы все сразу, либо (2) начал бы догадываться о вещах. Ни одно из этих решений не очень практично.

Answer 3

Один из способов облегчить BoundsChecker - исключить из инструментария все, кроме нескольких интересующих вас модулей. Я знаю, это не очень хорошо, потому что, если бы вы знали, где произошла утечка, вам не понадобился бы BoundsChecker. Обычно я рекомендую сначала использовать режим активной проверки BC, когда доступно только отслеживание памяти. Вы пропускаете валидацию API, но вы всегда можете запустить ее отдельно. После того, как вы запустите Active Check, и вы получите подсказки о том, какие модули имеют тенденцию вызывать проблемы, только тогда вы включаете инструментарий для интересующего вас модуля или модулей и их зависимостей. Мы знаем, что Final Check очень медленный, но, как правильно говорит Мистиано, с Final Check не только BC сохраняет график всех выделенных блоков, но также все указатели и контексты для них. В этом и заключается магия того, как Final Check может выявить утечки и повреждения в момент возникновения, а не только при завершении работы приложения или неисправности. Бесстыдная вилка: я работаю в команде DevPartner. Мы выпускаем DPS 10.5 4 февраля 2011 года с поддержкой приложений x64 в BC. В отличие от относительно старой и недооцененной BC64 для Itanium, которая предоставляла только Active Check, DPS 10.5 обеспечивает полную поддержку Final Check для приложений x64, как для чистого C ++, так и для собственных модулей, работающих в процессах .NET. См. Microfocus.com под MF Developer для деталей.