Ядро ядра в Linux

Я хочу создать дамп ядра, когда мой процесс выйдет из строя. В настоящее время я придерживаюсь такого подхода:

  • Создайте специальную "отладочную" версию программы, используя "-g" gcc/g++.
  • Выполнить "ulimit -c неограниченное"
  • Теперь мы получаем дамп ядра при сбое программы.

Но я хочу свести к минимуму количество шагов, чтобы:

  • Дамп ядра всегда должен создаваться. Даже если это "релиз". Пользователь не должен запрашивать команду "ulimit -c unlimited" вручную.
  • Эта базовая обратная линия дампа должна быть способна предоставить файл, функцию, номер строки вызовов. Это трассировка стека в удобочитаемой форме.
  • Я не хочу создавать программу как сборку отладки с помощью "-g". По крайней мере, он не должен содержать никакой другой информации для отладки, которая не требуется для создания отслеживаемой пользователем трассировки стека. Потому что это будет выпускная версия программы.

У меня есть два вопроса:

  • Как создать основной дамп в сборке "release" программы?
  • Всегда. Без ручного выполнения "ulimit -c unlimited"

ОТВЕТЫ

Ответ 1

Обычным решением является создание с -g и удаление информации об отладке перед выпуском файла. Найдите команду "strip". Вы сохраняете файл с отладочной информацией и используете его для отладки основных дампов, которые вы получаете от клиентов.

Если вы хотите напечатать человекочитаемую обратную трассировку на компьютере пользователя, вам нужно будет распространять двоичные файлы с (некоторой) информацией об отладке. Найдите функцию backtrace() в glibc.

Обратите внимание, что будут созданы дампы ядра (если ulimit установлен соответствующим образом), даже если ваш двоичный файл не содержит отладочную информацию.

Лучший способ обеспечить создание дампа ядра - это, вероятно, выполнить ваш двоичный файл из script, который устанавливает ulimit перед запуском двоичного файла.

Ответ 2

  • Что касается основного предела, вы можете сделать это самостоятельно в C, вызвав setrlimit.
  • В системе GNU (glibc) или BSD вы можете получить обратную трассировку, вызвав backtrace и связанные системные вызовы. Затем вам нужно будет перевести адреса функций в имена функций, запустив addr2line (или дублируя его функциональные возможности).
  • Просто не используйте -g, вы все равно можете получить обратную трассировку (кроме того, что встроенные функции не отображаются).

Ответ 3

Вы можете попробовать google-coredumper:

Оптимальный инструмент для создания GDB-считываемых coredumps из многопоточных приложений - во время работы программы. Библиотека coredumper может быть скомпилирована в приложения для создания дампов ядра запущенной программы без прерывания.

http://sourceforge.net/projects/goog-coredumper/

Ответ 4

  • В Linux нет версии "выпуска" и "отладки". Вы просто создаете программу с отладочной информацией при использовании "-g". Вы можете удалить эту информацию.

Обновление
На самом деле, я думаю, я должен сказать о одной возможной разнице между версиями отладки и выпуска, которые я не упоминал в своем сообщении. Версия выпуска может быть построена с помощью определения NDEBUG, чтобы избавиться от всех assert() в программе. Отладочные версии наоборот должны быть построены без определения NDEBUG, поскольку assert() помогает находить ошибки.

Однако, если вы не используете assert(), разница не будет.

  1. Пользователь может установить ulimit -c неограниченно в своем профиле.

  2. Backtrace программы, скомпилированной с некоторой оптимизацией, часто не дает номер строки, который полезен.

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

  4. How to create a core dump in the "release" build of a program? Это не ваша ответственность, это ответственность ОС.

Ответ 5

Вряд ли вы получите приличную стеклу в человеческом обличье, если код - это режим выпуска/высоко оптимизированная версия. Используйте ключ -g или забудьте о том, что вы вообще делаете stacktrace... у вас не может быть обоих! Что возвращается к этому моменту - похоже, вы ожидаете, что код рухнет даже в производственной среде???

Почему бы вам не исправить код и убедиться, что он работает первым ... code smells.... sniff sniff

Изменить: Хорошо, я, возможно, столкнулся с немного суровым в своем комментарии выше, я не собирался быть суровым там... на благо читателей, я включил ссылку на другой вопрос, размещенный здесь, и в этом answer, который я дал, использует сигналы для создания трассировки стека и перенаправления на файл. Он поможет в решении вопроса OP и поможет ему в поиске и устранении неисправностей...