Ядро сброшено, но файл ядра не находится в текущем каталоге?

Во время работы программы на Си написано "(core dumped)", но я не вижу никаких файлов по текущему пути.

Я установил и проверил ulimit:

ulimit -c unlimited 
ulimit -a

Я также пытался найти файл с именем "core", но не получил файл дампа ядра?
Любая помощь, где мой основной файл?

Ответ 1

Прочитайте /usr/src/linux/Документация/sysctl/kernel.txt.

[/proc/sys/kernel/] core_pattern используется для указания имени шаблона ядра dumpfile.

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

Вместо того, чтобы записывать основной дамп на диск, ваша система настроена на отправку его в программу abrt. Автоматический отчет об ошибках, возможно, не так документирован как должен быть...

В любом случае, быстрый ответ заключается в том, что вы должны найти свой основной файл в /var/cache/abrt, где abrt сохраняет его после вызова. Аналогично, другие системы, использующие Apport, могут выкидывать ядра в /var/crash и т.д.

Ответ 2

В недавнем Ubuntu (12.04 в моем случае) можно было напечатать "Ошибка сегментации (core dumped)", но основной файл не появился там, где вы могли бы ожидать его (например, для локально скомпилированной программы).

Это может произойти, если у вас есть размер основного файла ulimit 0 (вы еще не сделали ulimit -c unlimited) - это значение по умолчанию для Ubuntu. Обычно это подавляло бы "(сбрасывание ядра)", ввязав вас в вашу ошибку, но на Ubuntu файлы corefiles отправляются на Apport (Система отчетности о сбоях Ubuntu) через /proc/sys/kernel/core_pattern, и это, похоже, вызывает вводящее в заблуждение сообщение.

Если Apport обнаруживает, что данная программа не является одной, ей следует сообщать о сбоях (что вы можете увидеть в /var/log/apport.log), оно возвращается к моделированию поведения ядра по умолчанию для размещения основного файла в cwd ( это делается в script /usr/share/apport/apport). Это включает в себя почитание ulimit, и в этом случае он ничего не делает. Но (я предполагаю), насколько это касается ядра, генерируется файл corefile (и передается по каналу apport), следовательно, появляется сообщение "Ошибка сегментации (ядро сбрасывается)".

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

(Кроме того, в общем случае основная страница руководства (5) - man 5 core - является хорошей ссылкой для того, где заканчивается ваш основной файл, и причины, по которым он не может быть записан.)

Ответ 3

С запуском systemd появился еще один сценарий. По умолчанию systemd будет хранить основные дампы в своем журнале, будучи доступными с помощью команды systemd-coredumpctl. Определено в файле core_pattern:

$ cat /proc/sys/kernel/core_pattern 
|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e

Такое поведение можно отключить с помощью простого "взлома":

$ ln -s /dev/null /etc/sysctl.d/50-coredump.conf
$ sysctl -w kernel.core_pattern=core      # or just reboot

Как всегда, размер дампов ядра должен быть равен или больше, чем размер сбрасываемого ядра, как это сделано, например, ulimit -c unlimited.

Ответ 4

Написание инструкций для получения дампа ядра под Ubuntu 16.04 LTS:

Как упомянул @jtn в своем ответе, Ubuntu делегирует отображение сбоев в apport, который в свою очередь отказывается записывать дамп, потому что программа не является установленным пакетом.
Чтобы решить эту проблему, мы должны убедиться, что apport также записывает файлы дампа ядра для непакетных программ. Для этого создайте файл ~/.config/apport/settings со следующим содержимым:
[main] unpackaged=true
Теперь снова закройте вашу программу и увидите, что ваши файлы сбоя генерируются в папке: /var/crash с такими именами, как *.1000.crash. Обратите внимание, что эти файлы не могут быть прочитаны GDB напрямую.
[Необязательно] Чтобы сделать дамп доступным для чтения с помощью gdb, выполните следующую команду:

apport-unpack <location_of_report> <target_directory>

Ссылки: Core_dump - Oracle VM VirtualBox

Ответ 5

Я мог бы подумать о двух следующих возможностях:

Как уже отмечалось, программа может chdir(). Является ли пользователь, запускающий программу, разрешенным для записи в каталог, на который он chdir() 'ed? Если нет, он не может создать дамп ядра.
По какой-то странной причине дамп ядра не называется core.* Для этого вы можете проверить /proc/sys/kernel/core_pattern. Кроме того, команда find, которую вы назвали, не сможет найти типичный дамп ядра. Вы должны использовать find / -name "*core.*", поскольку типичным именем coredump является core.$PID

Ответ 6

Если вам не хватает базовых дампов для двоичных файлов на RHEL и при использовании abrt, убедитесь, что /etc/abrt/abrt-action-save-package-data.conf

содержит

ProcessUnpackaged = yes

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

Ответ 7

Для fedora25 я мог найти файл ядра в

/var/spool/abrt/ccpp-2017-02-16-16:36:51-2974/coredump

где ccpp-2017-02-16-16:36:51-2974" is pattern "%s %c %p %u %g %t %P % в соответствии с `/proc/sys/kernel/core_pattern '

Ответ 8

Мои усилия в WSL были неудачными.

Для тех, кто работает в подсистеме Windows для Linux (WSL), в настоящее время существует проблема с отсутствующими файлами дампа памяти.

Комментарии указывают на то, что

Это известная проблема, о которой мы знаем, это то, что мы расследуем.

Выпуск Github

Обратная связь для разработчиков Windows

Ответ 9

В Ubuntu18.04 самый простой способ получить файл ядра - ввести приведенную ниже команду, чтобы остановить службу apport.

sudo service apport stop

Затем перезапустите приложение, вы получите файл дампа в текущем каталоге.

Ответ 10

ulimit -c unlimited заставил файл ядра корректно появиться в текущем каталоге после "сброса ядра".

Ответ 11

Я на Linux Mint 19 (на основе Ubuntu 18). Я хотел, чтобы в текущей папке были файлы coredump. Я должен был сделать две вещи:

Измените /proc/sys/kernel/core_pattern (на # echo "core.%p.%s.%c.%d.%P > /proc/sys/kernel/core_pattern или # sysctl -w kernel.core_pattern=core.%p.%s.%c.%d.%P)
Повышение лимита для размера основного файла на $ ulimit -c unlimited

Это было написано уже в ответах, но я написал, чтобы подвести итог кратко. Интересно, что изменение лимита не требовало привилегий суперпользователя (так как https://askubuntu.com/info/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user не-root может только снизить предел, так что это было неожиданно - комментарии по этому поводу приветствуются).