Возврат из обработчика сигнала фатального по умолчанию сигнала - PullRequest
Новая
       35

Возврат из обработчика сигнала фатального по умолчанию сигнала

1 голос
/ 26 сентября 2019

Я хочу иметь обработчик сигналов для фатальных сигналов, который по умолчанию настроен на дамп ядра, который будет регистрировать вхождение, а затем ядро ​​все равно будет сбрасываться (если не отключено с помощью ulimit или шаблона ядра).

У меня естьпроверил (в Linux 4.15), что если обработчик сигнала просто возвращается, это то, что происходит.Однако в документации я не нашел ни одного явного утверждения, которое бы четко указывало на это.

Так определено ли это в документации POSIX или Linux, что произойдет, когда обработчик сигнала вернется и где?

1 Ответ

1 голос
/ 26 сентября 2019

Основные файлы имеют определение в POSIX.1-2017 XBD ( 3.117 Основной файл ):

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

POSIX.1-2017 XSH ( 2.4.3 Сигнальные действия , под SIG_DFL )содержит следующий текст (с любой выделенной частью отныне, означающей, что соответствующий текст в стандарте заштрихован XSI):

Если действие по умолчанию завершает процесс ненормально, процесс завершаетсякак при вызове _exit(), за исключением того, что статус, доступный для wait(), waitid() и waitpid(), указывает на аварийное завершение сигналом. Если действие по умолчанию заключается в ненормальном завершении процесса с помощью дополнительных действий, могут также возникнуть определенные пользователем ненормальные действия завершения, такие как создание файла ядра.

В XBD( 13. Заголовки , под ) мы видим SIGABRT, SIGBUS, SIGFPE, SIGILL, SIGQUIT, SIGSEGV, SIGSYS, SIGTRAP, SIGXCPU и SIGXFSZ помечены как

A - Аварийное завершение процесса с дополнительными действиями .

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

Однако каждый сигнал с действием по умолчанию "A"в POSIX указан с расположением по умолчанию «Core» в руководстве Linux (signal(7)).Это может быть то, к чему относится следующий отрывок руководства о SIGSYS, SIGXCPU и SIGXFSZ:

Linux 2.4 соответствует требованиям POSIX.1-2001 для этих сигналов, заканчиваяпроцесс с дампом ядра.

Как показывают приведенные выше выдержки из POSIX, в POSIX.1-2017 это не является жестким требованием.

Теперь это не отвечаетвопрос, если регистрация функции перехвата сигнала сводит на нет действие сигнала аварийного завершения.Я полагаю, что если это произойдет, это приведет к неопределенному поведению по крайней мере для нескольких сигналов, как в следующем абзаце из XSH ( 2.4.3 Действия с сигналом , в Указатель на функцию):

Поведение процесса не определено после нормального возврата из функции перехвата сигнала для SIGBUS, SIGFPE, SIGILL или SIGSEGV сигнал, который не был сгенерирован kill(), sigqueue() или raise().

Поэтому, чтобы избежать UB во всех случаях, я считаю, что вам нужно сбросить расположение сигнала на SIG_DFL и затем все равно повторно raise() сигнал из обработчика сигнала.Кроме того, любые обработчики, перехватывающие эти сигналы, вероятно, должны работать в альтернативном стеке сигналов, но я не совсем уверен, сделает ли это это вообще безопасным, и если это вообще так.

...