core dumped - но основной файл не находится в текущем каталоге?

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

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

ulimit -c unlimited 
ulimit -a

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

233
c coredump linux

8 ответов

читать / usr/src/linux/документация/sysctl / ядро.txt.

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

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

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

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

211

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

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

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

в конечном счете PEBKAC за то, что забыл установить ulimit, но вводящее в заблуждение сообщение заставило меня думать, что я схожу с ума на некоторое время, задаваясь вопросом, Что ест мои corefiles.

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

185

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

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

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

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

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

68

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

  1. как @jtn упомянул в своем ответе, Ubuntu делегирует отображение сбоев apport, который в свою очередь отказывается писать дамп, потому что программа не является установленным пакетом. Before making changes

  2. чтобы устранить проблему, нам нужно убедиться apport пишет файлы дампа ядра для non-package программы, а также. Для этого, создайте файл с именем ~/.config/apport / настройки следующего содержания:
    [main] unpackaged=true

  3. теперь сбой программы снова, и увидеть ваши файлы аварии генерируются в папке: / var / crash С такими именами, как *.1000.crash. Обратите внимание, что эти файлы не могут быть прочитаны gdb напрямую. After making changes

  4. [необязательно] чтобы сделать дампы readble на ГДБ, выполните следующую команду:

    apport-unpack <location_of_report> <target_directory>

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

21

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

  1. как уже указывали другие, программа может chdir(). Разрешено ли пользователю, запускающему программу, записывать ее в каталог chdir() ' ed to? Если нет, он не может создать дамп ядра.

  2. по какой-то странной причине дамп ядра не по имени core.* Вы можете проверить /proc/sys/kernel/core_pattern для этого. Кроме того, команда find, которую вы назвали, не найдет типичный дамп ядра. Вы должны использовать find / -name "*core.*", как типичное имя coredump является core.$PID

10

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

содержит 

ProcessUnpackaged = yes

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

6

для 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'

3

мои усилия в WSL были безуспешными.

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

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

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

выпуск Github

Отзывы Разработчиков Windows

2