Где я могу найти дамп памяти в Ubuntu 16.04LTS?

Содержание

Вопрос или проблема
Ответ или решение
Теория
Пример
Применение

Вопрос или проблема

У меня есть программа на C++, которая выполняет то, что должна, но, должно быть, есть проблема с указателем, так как она падает в конце и создает core dump. Моя проблема в том, что я не могу найти файл core, поэтому не могу его отладить.

Я попробовал

ulimit -c unlimited
ulimit -a

и теперь размер файла установлен как неограниченный, но я все равно не могу найти core. Я попробовал во всех указанных папках здесь, но, похоже, core файл не создается.

Где я могу его найти?

В Ubuntu core dumps обрабатываются Apport и могут находиться в /var/crash/. Но они по умолчанию отключены в стабильных выпусках.

Чтобы включить Apport, выполните: sudo systemctl enable apport.service или sudo service apport start.

Чтобы отключить, выполните: sudo systemctl disable apport.service или sudo service apport stop, чтобы вернуться к обычному методу core dumping. См. Как включить или отключить Apport?.

Чтобы отключить навсегда, отредактируйте файл /etc/apport/crashdb.conf и закомментируйте следующую строку:

'problem_types': ['Bug', 'Package'],

добавив символ решетки (#) в начале строки.

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

Вы также можете проверить core_pattern, как ядро обрабатывает core dumps:

$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c

Так что даже если core файлы отключены через ulimit, apport все равно будет захватывать сбой.

См. также:

Все вышеперечисленное не сработало для меня…
Я заглянул в /var/log/apport.log:

cat /var/log/apport.log

и увидел имя файла:

ERROR: apport (pid 3426) Пн Ноя 8 14:34:07 2021: запись core dump в core._home_guest_a_out.1000.4 ...

и затем я искал по всей системе

sudo find . -name "core._home_guest_a_out.1000.4..."

Я нашел core dump в /var/lib/apport/coredump/

Для тех, кто ищет в Google: (в моем случае — Ubuntu 16.04 и 18.04 и пользовательское приложение) /var/crash все еще пуст, так что быстрый способ справиться с созданием core (при условии, что вы, например, используете соответствующую настройку встроенного ulimit) был

sudo sysctl -w kernel.core_pattern=core.%u.%p.%t # чтобы включить создание core

systemctl restart apport # чтобы восстановить стандартные настройки apport
# которые, кстати, были "|/usr/share/apport/apport %p %s %c %d %P" (без кавычек)

Источники:

Ответ или решение

Вопрос о том, где искать файл сдампа памяти (core dump) в Ubuntu 16.04, является актуальным для многих разработчиков, особенно при работе с приложениями на языках, таких как C++. Проблемы с указателями в C++ могут привести к сбоям приложений и генерации сдампов памяти, которые нужны для диагностики ошибок. Однако по умолчанию конфигурация Ubuntu может препятствовать созданию сдампов, что делает задачу их поиска более сложной. Возможности решения данной проблемы и того, где можно найти сдамп памяти, обсудим ниже, следуя методу Теория-Практика-Применение (TEA).

Теория

Сдампы памяти представляют собой файлы, которые содержат снимки состояния памяти процесса на момент его сбоя. В Ubuntu 16.04 работа с сдампами контролируется системой Apport, которая управляет процессом их создания и хранения. По умолчанию Apport может быть отключен в стабильных версиях Ubuntu для повышения производительности, что затрудняет доступ к сдампам.

Основные факторы, влияющие на создание и хранение сдампов памяти в Ubuntu:

Ограничения системы: Команда ulimit используется для определения ограничений на размер файлов сдампов. Команда ulimit -c unlimited снимает ограничения на размер сдампов.
Apport: Это системная служба, которая перехватывает сдампы памяти и сохраняет их в определённых местах, таких как /var/crash/. Apport может управляться посредством systemctl или service.
Паттерн ядра (core_pattern): Это настройка, которая определяет, как ядро системы Linux обрабатывает сдампы. Значение core_pattern может указывать на использование Apport для обработки сдампов.

Пример

Представьте, что у вас есть приложение на C++, которое падает в конце своей работы. Вы сделали следующие шаги:

Использовали ulimit -c unlimited, чтобы снять ограничения на размер сдампа.
Проверили текущие значения ulimit командой ulimit -a, чтобы убедиться в правильности настроек.
Обратились к настройке /proc/sys/kernel/core_pattern, чтобы понять режим обработки сдампов.

В результате, даже после изменения настроек, сдампы не появились в ожидаемом месте.

Применение

Для решения вашей проблемы и нахождения файла сдампа, выполните следующие шаги:

Активируйте Apport: Убедитесь, что Apport активирован. Используйте команды sudo systemctl enable apport.service и sudo service apport start, чтобы включить службу.
Измените настройки kernel core pattern: Команда sudo sysctl -w kernel.core_pattern=core.%u.%p.%t изменит текущие настройки, позволив сохранять сдампы в формате файла, который будет размещён рядом с исполняемым файлом.
Поиск сдампа:
- Иногда Apport может записывать сдампы в /var/lib/apport/coredump/. Выполните поиск посредством команды find /var -name "core.*" для нахождения всех возможных сдампов.
- Если сдампы по-прежнему не создаются, убедитесь, что конфигурация Apport не вмешивается в процесс. Для этого вы можете временно отключить Apport с помощью sudo systemctl stop apport.service.
Дополнительные настройки:
- Проверьте ошибки в /var/log/apport.log, чтобы получить более полное представление о проблемах с Apport.
- Измените файл /etc/apport/crashdb.conf, чтобы модифицировать настройки "problem_types", если это необходимо для вашего случая.

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

Рекомендуется интегрировать данные процедуры в процессы разработки и тестирования вашего приложения, чтобы вовремя идентифицировать и устранять ошибки, потенциально приводящие к сбоям. Такой подход поможет повысить стабильность и надёжность программного обеспечения, что крайне важно в профессиональной среде.