Как сгенерировать дамп ядра в Linux при ошибке сегментации?

Это зависит от того, какую оболочку вы используете. Если вы используете bash, то команда ulimit управляет несколькими настройками, относящимися к выполнению программы, например, следует ли выгрузить дамп ядра. Если вы напечатаете

ulimit -c unlimited

тогда это скажет bash, что его программы могут выгружать ядра любого размера. Вы можете указать размер, например 52M, вместо неограниченного, если хотите, но на практике в этом нет необходимости, поскольку размер основных файлов, вероятно, никогда не будет для вас проблемой.

В tcsh вы должны ввести

limit coredumpsize unlimited

По умолчанию вы получите файл ядра. Убедитесь, что текущий каталог процесса доступен для записи, иначе основной файл не будет создан.

В конце я подключил gdb к процессу до его сбоя, а затем, когда он получил segfault, я выполнил команду generate-core-file. Это принудительное создание дампа ядра.

Возможно, вы могли бы сделать это таким образом, эта программа является демонстрацией того, как перехватить ошибку сегментации, и передает оболочку отладчику (это исходный код, используемый в AIX) и печатает трассировку стека до точки ошибки сегментации. Вам нужно будет изменить переменную sprintf, чтобы использовать gdb в случае Linux.

#include <stdio.h>
#include <signal.h>
#include <stdlib.h>
#include <stdarg.h>

static void signal_handler(int);
static void dumpstack(void);
static void cleanup(void);
void init_signals(void);
void panic(const char *, ...);

struct sigaction sigact;
char *progname;

int main(int argc, char **argv) {
    char *s;
    progname = *(argv);
    atexit(cleanup);
    init_signals();
    printf("About to seg fault by assigning zero to *s\n");
    *s = 0;
    sigemptyset(&sigact.sa_mask);
    return 0;
}

void init_signals(void) {
    sigact.sa_handler = signal_handler;
    sigemptyset(&sigact.sa_mask);
    sigact.sa_flags = 0;
    sigaction(SIGINT, &sigact, (struct sigaction *)NULL);

    sigaddset(&sigact.sa_mask, SIGSEGV);
    sigaction(SIGSEGV, &sigact, (struct sigaction *)NULL);

    sigaddset(&sigact.sa_mask, SIGBUS);
    sigaction(SIGBUS, &sigact, (struct sigaction *)NULL);

    sigaddset(&sigact.sa_mask, SIGQUIT);
    sigaction(SIGQUIT, &sigact, (struct sigaction *)NULL);

    sigaddset(&sigact.sa_mask, SIGHUP);
    sigaction(SIGHUP, &sigact, (struct sigaction *)NULL);

    sigaddset(&sigact.sa_mask, SIGKILL);
    sigaction(SIGKILL, &sigact, (struct sigaction *)NULL);
}

static void signal_handler(int sig) {
    if (sig == SIGHUP) panic("FATAL: Program hanged up\n");
    if (sig == SIGSEGV || sig == SIGBUS){
        dumpstack();
        panic("FATAL: %s Fault. Logged StackTrace\n", (sig == SIGSEGV) ? "Segmentation" : ((sig == SIGBUS) ? "Bus" : "Unknown"));
    }
    if (sig == SIGQUIT) panic("QUIT signal ended program\n");
    if (sig == SIGKILL) panic("KILL signal ended program\n");
    if (sig == SIGINT) ;
}

void panic(const char *fmt, ...) {
    char buf[50];
    va_list argptr;
    va_start(argptr, fmt);
    vsprintf(buf, fmt, argptr);
    va_end(argptr);
    fprintf(stderr, buf);
    exit(-1);
}

static void dumpstack(void) {
    /* Got this routine from http://www.whitefang.com/unix/faq_toc.html
    ** Section 6.5. Modified to redirect to file to prevent clutter
    */
    /* This needs to be changed... */
    char dbx[160];

    sprintf(dbx, "echo 'where\ndetach' | dbx -a %d > %s.dump", getpid(), progname);
    /* Change the dbx to gdb */

    system(dbx);
    return;
}

void cleanup(void) {
    sigemptyset(&sigact.sa_mask);
    /* Do any cleaning up chores here */
}

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

Есть еще кое-что, что может повлиять на создание дампа ядра. Я столкнулся с такими:

• каталог для дампа должен быть доступен для записи. По умолчанию это текущий каталог процесса, но его можно изменить, установив /proc/sys/kernel/core_pattern.
• в некоторых случаях значение ядра в /proc/sys/fs/suid_dumpable может препятствовать генерации ядра.

Есть и другие ситуации, которые могут помешать генерации, которые описаны на странице руководства - попробуйте man core.

Чтобы активировать дамп ядра, выполните следующие действия:

1. В /etc/profile прокомментируйте строку:

   # ulimit -S -c 0 > /dev/null 2>&1
   

2. В /etc/security/limits.conf закомментируйте строку:

   *               soft    core            0
   

3. выполните cmd limit coredumpsize unlimited и проверьте его с помощью cmd limit:

   # limit coredumpsize unlimited
   # limit
   cputime      unlimited
   filesize     unlimited
   datasize     unlimited
   stacksize    10240 kbytes
   coredumpsize unlimited
   memoryuse    unlimited
   vmemoryuse   unlimited
   descriptors  1024
   memorylocked 32 kbytes
   maxproc      528383
   #
   

4. чтобы проверить, записан ли основной файл, вы можете убить соответствующий процесс с помощью cmd kill -s SEGV <PID> (не требуется, на всякий случай, если не будет записан основной файл, это можно использовать в качестве проверки):

   # kill -s SEGV <PID>
   

После того, как corefile был записан, не забудьте снова деактивировать настройки coredump в соответствующих файлах (1./2./3.)!

Как объяснялось выше, настоящий вопрос, который задается здесь, заключается в том, как включить дампы ядра в системе, где они не включены. Здесь дан ответ на этот вопрос.

Если вы пришли сюда в надежде узнать, как сгенерировать дамп ядра для зависшего процесса, ответ будет

gcore <pid>

если gcore недоступен в вашей системе, тогда

kill -ABRT <pid>

Не используйте kill -SEGV, так как это часто вызывает обработчик сигнала, что затрудняет диагностику зависшего процесса.

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

sysctl kernel.core_pattern

или же:

cat /proc/sys/kernel/core_pattern

где %e - это имя процесса, а %t - системное время. Вы можете поменять его в /etc/sysctl.conf и перезагрузить sysctl -p.

Если файлы ядра не генерируются (проверьте это: sleep 10 & и killall -SIGSEGV sleep), проверьте ограничения: ulimit -a.

Если размер вашего основного файла ограничен, запустите:

ulimit -c unlimited

сделать его безграничным.

Затем проверьте еще раз, если выгрузка ядра прошла успешно, вы увидите «(core dumped)» после индикации ошибки сегментации, как показано ниже:

Segmentation fault: 11 (core dumped)

См. Также: ядро сброшено - но файл ядра отсутствует в текущем каталоге?

Ubuntu

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

Для получения дополнительной информации, пожалуйста, проверьте: Где мне найти дамп ядра в Ubuntu?.

macOS

Для macOS см .: Как сгенерировать дампы ядра в Mac OS X?

Для Ubuntu 14.04

1. Проверьте, включен ли дамп ядра:

   ulimit -a
   

2. Одна из строк должна быть:

   core file size          (blocks, -c) unlimited
   

3. Если не :

   gedit ~/.bashrc и добавьте ulimit -c unlimited в конец файла и сохраните, перезапустите терминал.

4. Создайте свое приложение с отладочной информацией:

   В Makefile -O0 -g

5. Запустите приложение, которое создает дамп ядра (файл дампа ядра с именем «core» должен быть создан рядом с файлом application_name):

   ./application_name
   

6. Запускаем под gdb:

   gdb application_name core
   

Лучше программно включить дамп ядра с помощью системного вызова setrlimit.

пример:

#include <sys/resource.h>

bool enable_core_dump(){    
    struct rlimit corelim;

    corelim.rlim_cur = RLIM_INFINITY;
    corelim.rlim_max = RLIM_INFINITY;

    return (0 == setrlimit(RLIMIT_CORE, &corelim));
}

Стоит упомянуть, что если у вас настроен systemd, тогда все будет немного иначе. При настройке обычно основные файлы передаются по конвейеру с помощью значения sysctl core_pattern через systemd-coredump(8). Rlimit размера основного файла обычно уже настроен как "неограниченный".

Затем можно получить дампы ядра с помощью coredumpctl(1).

Хранилище дампов ядра и т.п. настраивается coredump.conf(5). На странице руководства coredumpctl есть примеры того, как получить файлы ядра, но вкратце это будет выглядеть так:

Найдите основной файл:

[vps@phoenix]~$ coredumpctl list test_me | tail -1
Sun 2019-01-20 11:17:33 CET   16163  1224  1224  11 present /home/vps/test_me

Получите файл ядра:

[vps@phoenix]~$ coredumpctl -o test_me.core dump 16163

Ubuntu 19.04

Сами по себе все остальные ответы мне не помогли. Но следующий итог сработал.

Создайте ~/.config/apport/settings со следующим содержимым:

[main]
unpackaged=true

(Это говорит apport также писать дампы ядра для пользовательских приложений)

чек: ulimit -c. Если он выводит 0, исправьте это с помощью

ulimit -c unlimited

На всякий случай перезапустите аппорт:

sudo systemctl restart apport

Файлы сбоев теперь записываются в /var/crash/. Но вы не можешь используете их с gdb. Чтобы использовать их с gdb, используйте

apport-unpack <location_of_report> <target_directory>

Дальнейшая информация:

• В некоторых ответах предлагается изменить core_pattern. Имейте в виду, что этот файл может быть перезаписан службой аппорта при перезапуске.
• Простая остановка аппорта не помогла
• Значение ulimit -c может измениться автоматически, пока вы пробуете другие ответы в Интернете. Обязательно проверяйте его регулярно во время настройки создания дампа ядра.

Рекомендации:

• https://stackoverflow.com/a/47481884/6702598