.png)
Сценарий (Ubuntu 16.04):
Я компилирую и запускаю программу на C (с -g, я получаю традиционный Segmentation Fault (core dumped), и затем (конечно) не нахожу никакого мифического файла "core". Некоторые раскопки говорят, что нужно изменить /proc/sys/kernel/core_patternс помощью команды с эффектом: echo '|tee /home/me/my_core_folder/my_core_file' | sudo tee /proc/sys/kernel/core_pattern, и после этого я перестаю получать (core dumped)и начинаю получать только простой Segmentation Fault. Я пробую такие вещи, как , gdb ./program_object_file.out core.pidкоторого, очевидно, не существует (я уже отчаивался), и, конечно, пробую простой , gdb ./a.outза которым следуют (gdb) core core.pidи варианты команд, где я спамлю tabключом, отчаянно пытаясь получить автодополнение, чтобы добраться туда, куда мне нужно.
Вопрос:
Есть ли какой-то общий способ добраться до дампов памяти? Я понимаю, что каждая машина, к которой я прикасаюсь, похоже, имеетТрансформеры Майкла Бэя-esque способность перенастраивать оборудование и программное обеспечение таким образом, что ни одно устройство, которым я владею, не будет работать нормально из коробки. Есть ли простой алгоритм/рецепт, которому я могу следовать, чтобы найти дампы ядра на своей машине, а также на машинах других людей? Я всегда обнаруживаю, что обучаю друзей таким вещам после немалого объема работы, чтобы заставить все работать у себя, и было бы неплохо иметь возможность запустить команду или что-то еще, чтобы сбросить файлы ядра в каталог, из которого был запущен исполняемый файл... есть ли способ сделать это, который должен работать на большинстве (я бы согласился на "некоторых") машин Linux/Unix?
решение1
Thecore(5)man-страница подробно описывает параметры, влияющие на дампы ядра, включая их наименование и т. д.
Чтобы ответить на ваш вопрос, нет универсального способа найти дамп ядра. По умолчанию дамп ядра находится впроцесстекущий рабочий каталог, разрешено ли процессу писать туда, достаточно ли места в содержащей его файловой системе, нет ли существующего дампа ядра (при некоторых обстоятельствах) и ulimitпозволяют ли это размер файла и ограничения на размер файла ядра (установленные или аналогичными механизмами). Но /proc/sys/kernel/core_patternпредоставляет множество различных способов обработки дампов ядра, поэтому вам действительно нужно взглянуть и на это, чтобы понять, что происходит.
В вашем случае я не знаю, почему ядро не было найдено изначально, но я знаю, почему вы перестали получать ядра после настройки перенаправления: при использовании канала в core_patternпрограмме обработкидолженбыть указан с использованием абсолютного пути. teeсам по себе не будет использоваться; необходимо указать /usr/bin/tee. Обратите внимание, что следует проявлять особую осторожность при использовании этого типа настройки в многопользовательских системах, поскольку программа, запускаемая для обработки дампа ядра, запускается как root.
На производных Debian я устанавливаюcorekeeper, который записывает дампы памяти в удобной для использования форме в каталоги пользователя в /var/crash.
решение2
(Перемещение ответа из OP в Вопросе в Ответ)
Я отметил ответ ниже как правильный, поскольку он помог мне определить, что на самом деле пошло не так, и я хотел бы вернуться к этому вопросу в будущем, чтобы немного подробнее рассказать об этом, но мое текущее решение (которое, как я подозреваю, будет работать на большинстве машин Linux) заключается в использовании следующих команд:
cat /proc/sys/kernel/core_pattern > ~/.core_pattern.bak
echo '|/usr/bin/tee ~/path_you_wish_to_dump_to/core/dump' | sudo tee /proc/sys/kernel/core_pattern
Это позволит создать резервную копию вашего предыдущего метода дампа ядра в скрытом файле ( .core_pattern.bak) в вашей домашней папке, который можно восстановить с помощью
sudo cp ~/.core_pattern.bak /proc/sys/kernel/core_pattern
и вторая команда заставит дампы ядра быть сброшены в папку, названную coreкак файл с именем dump. Очевидно, вы можете повозиться с этим форматом, чтобы получить шаблон, который вам больше нравится. Однако следует отметить, что, насколько я могу судить, это будет хранить только один дамп ядра за раз (каждый новый будет затирать старые), но поскольку, если я лично когда-либо проверяю дамп ядра, то это для программы, которая только что запущена, и поскольку мне не нужно хранить старые дампы, это хорошее решение для меня и для большинства приложений, которые мои друзья будут создавать и отлаживать. Я бы с удовольствием изменил этот ответ немного позже, чтобы включить такие вещи, как PID, который вызвал segfault (в основном просто сахар сверху, поскольку -опять же - я обычно знаю, какая программа вызвала segfault, так как я только что запустил ее), но этого, безусловно, будет достаточно для меня и для многих людей, я думаю.
И последнее, но не менее важное: чтобы просмотреть дамп, просто выполните команду:
gdb ./executable_that_crashed ~/path_you_wish_to_dump_to/core/dump
Предположим, что вы находитесь в папке, где вы скомпилировали/запустили исполняемый файл, который вызывает ошибку сегментации.