Как избежать записи файла ядра и ускорить генерацию трассировки

Прежде чем я задам свой вопрос, я кратко опишу, как я получаю обратную связь от своих клиентов. Пишу приложение на C ++ на linux (opensuse).

Это приложение запускается скриптом (пусковой установкой), и в случае сбоя приложения создается дамп ядра (поскольку ulimit -c unlimited). Затем программа запуска генерирует обратную трассировку из основного файла с помощью gdb и снова запускает приложение, что дает пользователю возможность отправить отчет о сбое, содержащий обратную трассировку.

Теперь моя проблема и мой вопрос:

  • проблема: дамп ядра может быть довольно большим (до 5 или 10 ГБ). Копирование основного файла занимает определенное время (до 2 минут). Это проблема моих клиентов: слишком много времени между сбоем и автоматическим перезапуском приложения.
  • вопрос: я генерирую трассировку с помощью gdb из 1) моей программы 2) основного файла. Когда приложение дает сбой, передает дамп ядра в программу по конвейеру.: могу ли я в этой программе напрямую прикрепить gdb к "умирающей" программе и сгенерировать трассировку, зарабатывая время на копирование основного файла на жесткий диск?

Заранее спасибо.

Просто замечание:


person Nico    schedule 21.11.2013    source источник
comment
Вы пытались уменьшить количество отладочной информации при сборке? Я имею в виду, например, использование -g1 вместо -g; и оптимизация -O1 или -O2   -  person jcm    schedule 23.11.2013


Ответы (2)


Существует отличный ответ о том, как получить трассировку стека без создания дампа ядра в форме копирования / вставки здесь.

Он сгенерирует трассировку стека в stderr, но вы можете легко сделать что-то другое, например, опубликовать данные трассировки стека с помощью HTTP и т. Д.

person sethcall    schedule 21.11.2013

Вам не нужно добавлять весь gdb только для того, чтобы отследить сбой программы. Просто перехватите сигнал, такой как SIGBUS, и при получении сигнала вы можете использовать backtrace () или просто вызвать gstack с pid вашей программы.

person Slava    schedule 21.11.2013
comment
Не должно работать надежно. Поскольку backtrace не является безопасным для асинхронных сигналов. См. безопасность сигналов (7) - person Basile Starynkevitch; 20.07.2018