Сбой программного обеспечения после резкого увеличения памяти рабочего набора процесса
Я задаю этот вопрос, потому что мы действительно застряли в поиске причины сбоя программного обеспечения. Я знаю, что такие вопросы, как «Почему происходит сбой программного обеспечения», не ценятся, но мы действительно не знаем, как найти проблему.
В настоящее время мы проводим долгосрочное тестирование нашего программного обеспечения. Чтобы найти потенциальные утечки памяти, мы использовали инструмент Windows Монитор производительности отслеживать несколько показателей памяти, таких как Частные байты, Рабочий набор а также Виртуальные байты.
Программное обеспечение работало довольно долго (около 30 часов) без каких-либо проблем. Он делает то же самое все время, читая изображение с жесткого диска, проводя некоторые проверки и показывая некоторые результаты.
И вдруг он падает. Изучив метрики памяти в мониторе производительности, мы увидели странный крутой взлет графика байтов рабочего набора в 10.17. Мы сталкивались с этим несколько раз, и, согласно дамп-файлам, код исключения всегда 0xc0000005: «поток пытался прочитать или записать виртуальный адрес, для которого у него нет соответствующего доступа», но он появляется в разных позициях, где не используются указатели.
Кто-нибудь знает, что может быть причиной такого крутого подъема рабочего набора и почему это может вызвать сбой программного обеспечения? Как мы можем узнать, если в нашем программном обеспечении есть ошибка, когда каждый раз, когда происходит сбой, положение сбоя находится в другом положении?
Приложение написано на C ++ и работает на Windows 7 32bit PC.
Решение
На самом деле это невозможно узнать из предоставленной вами информации, но я бы посоветовал вам повредить память (отсюда и нарушение прав доступа). Это может быть проблема переполнения буфера … например, отсутствует null символ из строки и так что-то добавляется бесконечно?
Следующим шагом рекомендуется загрузить пакет средств отладки для Windows. Настроить WinDbg с вашими правильными файлами символов, и проанализируйте трассировку стека, чтобы найти общую область сбоя. В зависимости от причины повреждения памяти это будет более или менее полезно. Вы могли повредить память задолго до того, как произойдет сбой.
В идеале также следует запустить инструмент статического анализа кода.
Другие решения
Учитывая имеющуюся у вас информацию, у вас мало шансов получить ответ. Вам нужно больше информации, а именно:
-
Получите больше информации (есть ли что-то конкретное в этих файлах, которые вызывают сбой? Как насчет файла «последний, но один»?)
-
Добавьте больше трассировки и логов (столько, сколько сможете, не делая это в 2 раза медленнее). По крайней мере, вы увидите, где он падает, а затем сможете добавить больше трассировки / регистрации вокруг этого места.
-
Поскольку вы работаете в Windows — рассмотрите возможность обработки c0000005 через _set_se_translator, конвертирование его в исключение C ++ и еще больше регистрации того, как это исключение не используется.
Для такого рода проблем не существует серебряной пули, только для сбора дополнительной информации и ее выяснения.
Постскриптум Как маловероятный выстрел — я видел похожие вещи, которые могут быть вызваны ошибкой в куче MS; если вы еще не используете LFH (не уверен, что это может быть по умолчанию сейчас) — с вероятностью 1% изменение кучи по умолчанию на LFH поможет.