Является ли спецификация неопределенного поведения SIG_IGN в отношении SIGFPE, SIGILL, SIGSEGV избыточной?
POSIX.1-2017 указывает в XSH 2.4.3 SIG_IGN, что
The behavior of a process is undefined after it ignores a SIGFPE, SIGILL, SIGSEGV, or SIGBUS signal that was not generated by kill(), sigqueue(), or raise().
и мне интересно, каково значение подчеркнутой части?
Можете ли вы игнорировать эти сигналы, генерируемые только вышеуказанными функциями, и при этом избежать вызова неопределенного поведения?
Ответы 2
Другими словами, это говорит о том, что если сигнал генерируется ядром в результате аппаратная ошибка или ловушка, то игнорирование такого сигнала имеет неопределенное поведение.
Вы не можете. Вы можете перехватить их и использовать SA_SIGINFO, чтобы различать отправленные ядром и пользователем варианты этих сигналов, или, если вы используете настоящий SIG_IGN, вы должны позаботиться о том, чтобы не спровоцировать ядро на генерацию этих сигналов (никаких недопустимых ссылок на память, недействительные инструкции и т. д.).
@nebel Потенциально можно повторно использовать эти сигналы для конкретных целей приложения, но большинство программ воздерживаются от этого, чтобы упростить жизнь. Но есть определенные варианты использования, которые требуют, чтобы приложения восстанавливались после этих сигналов, например, приложения с JIT-компиляторами могут просто дать сбой JIT-функции, если она сгенерировала, скажем, SIGFPE, но не приведет к сбою приложения.
@PSkocik Я не знал о SA_SIGINFO предоставлении соответствующих данных, чтобы различать пойманные сигналы, спасибо. Даже тогда я не вижу большой пользы даже в полностью соответствующей программе (например, в той, которая не вызывает аппаратных сбоев) в настройке SIG_IGN для этих сигналов. Может быть, для какого-нибудь модульного теста POSIX API, который сам генерирует SIGFPE и т. д.?
@MaximEgorushkin, но тогда бы вы не настраивали их на действие SIG_IGN. И это тоже в значительной степени не определено, если вы в конечном итоге не вызовете abort() при их захвате, я думаю: Поведение процесса не определено после нормального возврата из функции перехвата сигнала для сигнала SIGBUS, SIGFPE, SIGILL или SIGSEGV, который не был сгенерирован kill(), sigqueue() или raise(). Так что, к сожалению, даже это нельзя использовать, если вы не вернете ненормально, что бы это ни значило.
@nebel Я думаю, вы слишком беспокоитесь о функции, которая не очень важна и существует просто потому, что «почему бы не разрешить это?».
@PSkocik Верно. Если вы превратите свой первый комментарий в ответ, я приму его. Я кое-чему научился из этого обмена, так что спасибо за терпение!
Вы не должны SIG_IGN-ore эти сигналы, если вы ожидаете, что ядро сгенерирует их.
Вы можете поймать их с помощью sigaction и SA_SIGINFO в .sa_flags и использовать SA_SIGINFO, чтобы затем использовать info->si_code в обработчике, чтобы различать варианты, отправленные ядром, и варианты, отправленные пользователем.
Если затем вы ничего не делаете в обработчике, если сигнал не был отправлен ядром, и выходите/прерываете работу, если это так, то с обработчиком SA_RESTART вы в основном получаете эмуляцию SIG_IGN в пользовательском пространстве, которая также работает с отправленным ядром SISGEV, SIGILL и др.
Если вы используете настоящие SIG_IGN, вы должны позаботиться о том, чтобы не спровоцировать ядро генерировать эти сигналы (никаких неверных ссылок на память, никаких неверных инструкций и т. д.).
Я думаю, что POSIX позволяет вам безопасно игнорировать SIGFPE, SIGILL, SIGSEGV или SIGBUS просто потому, что нет веских причин категорически запрещать игнорирование этих сигналов при любых обстоятельствах, но я не думаю, что в противном случае эта функция имеет большое значение.
Конечно. Но зачем вообще проводить это различие? Я не вижу никакого способа, которым процесс может игнорировать сигналы, сгенерированные
kill(),sigqueue()иraise(), не подвергаясь потенциальному воздействию этого поведения, вызывающего UB. Есть ли?