Анализ катастрофического отказа Linux

Что лучший способ состоит в том, чтобы проанализировать катастрофические отказы на Linux?

Мы ожидаем создавать программное обеспечение и обеспечивать версию выпуска тестерам. Тестеры не могут, помнят, как воспроизвести катастрофический отказ, или катастрофический отказ может быть полностью неустойчивым. У них также не будет среды разработки на их машинах. Программное обеспечение записано в C/C++ и скомпилировано в собственный машинный код для распределения.

9
задан doron 27 July 2010 в 13:09
поделиться

5 ответов

Дампы ядра полезны, но они не всегда сообщают вам все, что вы хотите знать о том, как вы оказались в состоянии ошибки.

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

Если возможно, вы должны создавать свои программы с максимальным количеством сгенерированных отладочных символов, а затем удалять их, если вы не хотите или не можете позволить вашим выпускным версиям иметь их, но сохраните копию каждой выпущенной версии с отладочными символами, которые вы можете соединиться с файлом ядра, если вам нужно отладить сбой.

3
ответ дан 4 December 2019 в 10:30
поделиться

Если у вас есть место на диске, позвольте приложению создавать свой coredump при сбое.

ulimit -c unlimited

Позже вы сможете отладить его с помощью GDB.

7
ответ дан 4 December 2019 в 10:30
поделиться

Помимо coredumping и трассировки стека, как уже отмечалось, убедитесь, что вы можете легко определить, какие версии ваших исполняемых файлов работают, и сможете ответить, какая версия каждого исходного файла входит в какую двоичную версию (т. е. потратьте некоторое время на систему управления исходным кодом и сценарии сборки). В противном случае ни файл ядра, ни трассировка стека не помогут.

3
ответ дан 4 December 2019 в 10:30
поделиться