Можете ли вы запустить и остановить Boundschecker (DevPartner)? - PullRequest
Новая
       26

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

1 голос
/ 23 января 2009

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

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

Ответы [ 3 ]

2 голосов
/ 23 января 2009

В последний раз я использовал 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);}

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

0 голосов
/ 29 января 2011

Один из способов облегчить 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 для деталей.

0 голосов
/ 15 августа 2010

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

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

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

...