Какой лучший способ найти повреждение кучи, которое происходит только при тестировании производительности?

Question

Программное обеспечение, над которым я работаю (написано на C ++), в настоящий момент имеет проблему с повреждением кучи.Наша команда по тестированию перфектов продолжает получать сбои WER, когда число пользователей, вошедших в систему, достигает определенного порога, но предоставленные мне дампы просто показывают повреждения в неподобающих областях (например, когда std :: string освобождает основную память),

Я пытался использовать Appverifier, и это вызвало ряд проблем, которые я сейчас исправил.Однако сейчас я нахожусь в ситуации, когда тестировщики могут как можно больше загружать машину с помощью Appverifier и выполнять ее без проблем, но при этом работать без Appverifier, но, по-моему, они могут привлечь больше пользователей и т. Д. Без него.Это означало, что я не смог получить дамп, который на самом деле показывает проблему.

У кого-нибудь есть какие-нибудь идеи относительно полезных методов или технологий, которые я могу использовать?Я сделал столько анализа, сколько смогу, на дампах повреждения кучи без appverifier, но я не вижу общих тем.Никакие потоки не делают ничего, что может быть связано одновременно с аварийным завершением, и аварийный поток невиновен, что заставляет меня думать, что повреждение произошло некоторое время назад.

Answer 1

Лучшим инструментом является Appverifier в сочетании с gFlags, но есть много других решений, которые могут помочь.

Например, вы можете указать проверку кучи каждые 16 операций malloc, realloc, free и _msize с помощьюследующий код:

#include <crtdbg.h>
int main( )
{
int tmp;

// Get the current bits
tmp = _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG);

// Clear the upper 16 bits and OR in the desired freqency
tmp = (tmp & 0x0000FFFF) | _CRTDBG_CHECK_EVERY_16_DF;

// Set the new bits
_CrtSetDbgFlag(tmp);
}

Answer 2

У вас есть мои симпатии: очень сложная проблема для отслеживания.

Как вы обычно говорите, это происходит за некоторое время до сбоя, как правило, в результате неправильной записи (например, запись в удаленную память,запуск в конце массива, превышение выделенной памяти в memcpy и т. д.).

В прошлом (в Linux, я полагаю, вы работаете в Windows), я использовал инструменты для проверки кучи (valgrindОчистите, инспектор Intel) но, как вы заметили, они часто влияют на производительность и, таким образом, скрывают ошибку.(Вы не говорите, является ли это многопоточным приложением, или обрабатывает набор переменных данных, таких как входящие сообщения).

Я также перегружал операторы new и delete для обнаружения двойного удаления, но это довольноспецифическая ситуация.

Если ни один из доступных инструментов не поможет, то вы сами по себе, и процесс отладки будет долгим.Лучший совет для этого, который я могу предложить, - поработать над сокращением сценария тестирования, который будет воспроизводить его.Затем попытайтесь уменьшить объем исполняемого кода, т. Е. Заглушить части функциональности.В конце концов, вы сосредоточитесь на проблеме, но я видел, как очень хорошие ребята потратили 6 недель или больше, отслеживая их в большом приложении (~ 1,5 млн. LOC).

Всего наилучшего.

Answer 3

Вы должны подробнее рассказать о том, что на самом деле делает ваше программное обеспечениеЭто многопоточный?Когда вы говорите о «количестве пользователей, вошедших в коробку», каждый пользователь открывает разные экземпляры вашего программного обеспечения в другой сессии?Является ли ваше программное обеспечение веб-сервисом?Инстансы общаются друг с другом (как с именованными каналами)?

Если ваша ошибка ТОЛЬКО возникает при высокой нагрузке и НЕ возникает, когда работает AppVerifier.Единственные две возможности (без дополнительной информации), о которых я могу подумать, это проблема параллелизма с тем, как вы реализовали многопоточность ИЛИ на тестовой машине проблема с оборудованием, которая проявляется только при большой нагрузке (если ваши тестеры использовали более одной машины)?).