Существует ли точка к захвату “segfault”?
Я знаю, что, учитывая достаточное количество контекста можно было надеяться использовать конструктивно (т.е. восстановиться) с segfault условия.
Но, действительно ли усилие стоит того? Если да, в какой ситуация (ситуации)?
6 ответов
Нельзя надеяться на выздоровление после сегрегации. Вы можете обнаружить, что это произошло, и, если возможно, сбросить соответствующее прикладное состояние, но вы не можете продолжить процесс. Это связано с тем, что (среди прочего)
- Поток, который вышел из строя, не может быть продолжен, поэтому единственными вариантами являются longjmp или прекращение потока. В любом случае, вы можете оставить мьютекс/блокировку в заблокированном состоянии, что заставит другие потоки ждать вечно
- Даже если этого не произойдет, вы можете утечка ресурсов
- Даже если вы не сделаете ни того, ни другого, сегментированный поток, возможно, оставил внутреннее состояние приложения непоследовательным, когда оно вышло из строя. Непоследовательное внутреннее состояние может привести к ошибкам в данных или последующему плохому поведению, что вызовет больше проблем, чем простое завершение
Так что в общем, нет смысла ловить его и делать что-либо EXCEPT, завершающее процесс довольно внезапно. Нет смысла пытаться записать (важные) данные обратно на диск или продолжать делать другую полезную работу. Есть некоторый смысл в демпинге состояния в лог-файлы - что делают многие приложения - и затем в выходе из него.
Возможно, полезной вещью будет выполнение() собственного процесса, или наличие сторожевого процесса, который перезапускает его в случае аварийного завершения работы. (NB: exec не всегда имеет хорошо определенное поведение, если ваш процесс имеет >1 поток)
.Нет. Я думаю, что это пустая трата времени - неисправность сегмента указывает на то, что в вашем коде что-то не так, и вам лучше найти это, изучив дамп ядра и/или ваш исходный код. Однажды, когда я попытался поймать неисправность сегмента, это привело меня в зал зеркал, чего я мог бы избежать, просто подумав о исходном коде. Больше никогда.
Ряд причин:
- Предоставление более подробной информации по конкретным приложениям для отладки аварии. Например, я упал на этапе 3 обработки файла 'x'.
- Чтобы проверить, доступны ли определенные области памяти. В основном это было сделано для того, чтобы удовлетворить API для встраиваемой системы. Мы попытались записать в область памяти и поймали сегмент, который говорил нам, что память доступна только для чтения.
- Сегмент, как правило, начинается с сигнала от MMU, который используется операционной системой для подкачки страниц памяти при необходимости. Если у операционной системы нет этой страницы памяти, то она перенаправляет сигнал на приложение.
a Ошибка сегментации - это действительно доступ к памяти, к которой у вас нет прав доступа (либо потому, что она не отображается, либо потому, что у вас нет прав, недействительный виртуальный адрес и т.д.). ).
В зависимости от основной причины, вы можете захотеть поймать в ловушку и обработать ошибку сегментации. Например, если вашей программе передан недействительный виртуальный адрес, она может записать этот segfault в журнал и затем выполнить некоторый контроль над повреждениями.
Сегментация не обязательно означает, что куча программ повреждена. Чтение недействительного адреса ( например, нулевой указатель) может привести к сегрегации, но это не значит, что куча повреждена. Кроме того, приложение может иметь несколько кучи в зависимости от времени выполнения на С.
.Есть очень продвинутые методы, которые можно реализовать, обнаружив ошибку сегментации, если вы знаете, что ошибка сегментации не является ошибкой. Например, вы можете защитить страницы, чтобы с них нельзя было читать, а затем перехватить SIGSEGV для выполнения «магического» поведения до завершения чтения. (См. Tomasz Węgrzanowski «Собственные программы Segfaulting для развлечения и получения прибыли» для примера того, что вы можете сделать, но обычно накладные расходы довольно высоки, так что это не стоит делать.)
Аналогичный принцип применяется к перехват исключения недопустимой инструкции (обычно в ядре) для имитации инструкции, которая не реализована на вашем процессоре.