Sigsegv segmentation fault qt как исправить

Разрабатывал на днях класс древовидного списка CTree, как раз создавал конструктор копирования.
Случайно забыл обнулить указатель в конструкторе копирования, что привело в дальнейшем к не всегда выпадающей ошибке доступа к памяти.
Разработка велась в Qt Creator. И ошибка доступа памяти приходила сообщением от ОС в виде сигнала SIGSEGV.

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

SIGSEGV — сигнал, посылаемый процессу при попытке обращения к несуществующей памяти или обращения с нарушением прав доступа (Segmentation Fault).
Данная ошибка может возникать при попытке обратиться к методу или члену по невалидному указателю, или при попытке обратиться к чужой области памяти.
К ошибке доступа памяти SIGSEGV могут привести следующие примеры кода:

// Пример 1. Не всегда может привести 
// к вызову SIGSEGV (Segmentation Fault)
myclass *ptr = new myclass;
delete ptr;
delete ptr;

// Пример 2. Более вероятно, 
// что сразу приведёт к SIGSEGV (Segmentation Fault)
int *ptr = (int*)(0x000000000);
delete ptr;

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

Кстати, помимо ошибки доступа памяти (при работе с указателями), можно получить и ошибку математических вычислений. Такая ошибка сопровождается приходом сигнала SIGFPE. Самый простой пример — это деление на нуль:

int x;
x = 1/0;

В этом случае также можно получить молчаливое или аварийное завершение программы. (Молчаливое завершение намного хуже, т.к. вы можете его попросту не заметить и ничего об этом не узнать).

Как сделать так, чтобы программа не завершалась молча?

Как перехватить ошибку доступа к памяти?
Как перехватить деление на ноль?
Ответ далее.

Для этого надо перехватить сигналы SIGSEGV, SIGFPE. (Кстати, не все сигналы могут быть перехвачены, более подробную информацию можно найти в соответствующей справке по функции signal).

За основу следующего примера был взят пример с «Обработка Segmentation Fault в C++».

Перехват сигналов SIGSEGV, SIGFPE в C++:

#include <windows.h>
#include <signal.h>

void handler_sigsegv(int signum)
{
    MessageBoxA(NULL,"SIGSEGV Error!","POSIX Signal",MB_ICONSTOP);
    // открепить обработчик и явно завершить приложение
    signal(signum, SIG_DFL);
    exit(3);
}

void handler_sigfpe(int signum)
{
    MessageBoxA(NULL,"SIGFPE Error!","POSIX Signal",MB_ICONSTOP);
    // открепить обработчик и явно завершить приложение
    signal(signum, SIG_DFL);
    exit(3);
}

void fall1()
{
    int* p = 0x00000000;
    *p = 10;
}
void fall2()
{
    int x;
    x = 1/0;
}

int main()
{
    // установим наши обработчики на два сигнала
    signal(SIGSEGV, handler_sigsegv);
    signal(SIGFPE, handler_sigfpe);

    // вызовем одну из ошибок
    fall1();
    fall2();

    return 0;
}

Внимание: в документации описан перечень безопасных функций, которые можно безопасно вызвать из обработчика сигнала SIGSEGV. Также не следует продолжать выполнять какие-то критические действия, т.к. память уже повреждена (какие именно повреждения — неизвестно).

Пример я компилировал в Qt Creator под операционной системой Windows, и он работал, ошибки отлавливались. Спасибо хабра-форуму, который подсказал решение этой проблемы. В результате работы примера, при возникновении ошибок, будут всплывать диалоговые окна, оповещающие об ошибке.

Для перехвата исключения деления на ноль, можно использовать технологию SEH, но возможно она работает только для Windows. И она также может перехватить не все сигналы.

По вопросам выделения памяти и «двойного» delete, можно почитать: http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.2

     После N-ного количества времени, потребовалось мне запустить одно приложение в Qt Creator’е (в ОС Windows XP) в режиме отладки. Как же я был неприятно удивлен, когда IDE поругалась на «Segmentation fault» и наотрез отказалось «дебажить» программу. Поначалу, казалось,что это результат несовместимости кода, набранного в более старой среде, и последней версии Qt SDK. Но программа прекрасно компилировалась и запускалась и в debug и release вариантах. Так «несовместимость версий» отпала, а вот таинственная «guard32.dll«, что загадочным образом подключалась к запускаемому приложению, просветила суть вещей :-).

       Путь к истине был долог и тернист, но не сломил он духа праведного и, в итоге, привел к Comodo Firewall. А точнее к той его части, что отвечает за контроль запускаемых приложений. Т.о. отключив Проактивную защиту Comodo Firewall, можно добиться желанного — отладка в Qt Creator запускается без каких-либо предупреждений или ошибок. Но это явно «не наш метод», поскольку даже после отключения нужно еще и перезагрузить ПК — дабы выгрузились соответствующие процессы. К тому же, согласитесь, не для того ставили программу защиты, что бы ей потом не пользоваться ;-). Что же делать, спросите вы? Обратиться к настройкам Проактивной защиты фаервола и указать директории игнорирования проверки внедрения shell-кода. Для этого необходимо:

1. Открыть главное окно Comodo Firewall и перейти на вкладку «Защита«.

2. На вкладке «Защита» выбрать пункт меню «Настройки Проактивной защиты«.

3. В открывшемся окне перейти на вкладку «Настройки контроля исполнения приложений«.

4. На вкладке «Настройки контроля исполнения приложений» нажать кнопку «Исключения«.

5. В открывшемся окне «Исключения» выбрать пункт меню «Добавить«=>»Обзор» (реализовано в виде кнопки).

6. В открывшемся окне выбрать директорию в которой у вас находиться разрабатываемый проект (кстати, директории могут добавляться по маске, поэтому можно сразу добавить корневую директорию содержащую все ваши проекты Qt, например, «C:myQt_projects«). Обратите внимание, что для добавления директории ее нужно «перетащить» в секцию справа!

7. Сохранить изменения. 

     Собственно, на этом манипуляции заканчиваются и можно возвращаться к работе в Qt Creator :-). Для тех же, у кого не стоит Comodo Firewall, но возникает аналогичная ситуация, рекомендую поэкспериментировать с установленными программами защиты (фаерволы, антивирусы, антитрояны и прочее) — в последнее время, очень часто, именно они становятся причинами «непонятных» ситуаций :-).

Вводная

C++ является «небезопасным» («unmanaged») языком, поэтому программы могут «вылетать» — аварийно завершать работу без сохранения данных пользователя, сообщения об ошибке и т.п. — стоит только, например, залезть в не инициализированную память. Например:

void fall()
{
  char * s = "short_text";
  sprintf(s,"This is very long text");
}

или

void fall()
{
  int * pointer = NULL;
  *pointer = 13;
}

Всем было бы лучше, если бы мы могли «отловить» падение программы — точно так же, как в java ловим исключения — и выполнить хоть что-то перед тем, как программа упадет (сохранить документ пользователя, вывести диалог с сообщением об ошибке и т.п.)

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

Способ 1: SEH

Если Вы используете OS Windows в качестве целевой ОС и Visual C++ в качестве компилятора, то Вы можете использовать Structured Exception Handling — расширение языка С++ от Microsoft, позволяющее отлавливать любые исключения, происходящие в программе.

Общий синтаксис обработки исключений выглядит следующим образом:

__try
{
  segfault1();
}
__except( condition1 )
{
  // обработка исключения, если condition1 == EXCEPTION_EXECUTE_HANDLER.
  // в condition1 может (должен) быть вызов метода, проверяющего 
  //    тип исключения, и возвращающего EXCEPTION_EXECUTE_HANDLER 
  //    если тип исключения соответствует тому, что мы хотим обработать
}
__except( condition2 )
{
  // еще один обработчик
}
__finally
{
  // то, что выполнится если ни один из обработчиков не почешется
}

Вот «работающий пример» — «скопируй и вставь в Visual Studio»

#include <stdio.h>
#include <windows.h>
#include <excpt.h>

int memento() // обработка Segfault
{
	MessageBoxA(NULL,"Memento Mori","Exception catched!",NULL);
	return 0;
}

void fall() // генерация segfault
{
	  int* p = 0x00000000;   
	  *p = 13;
}

int main(int argc, char *argv[])
{
	__try
	{
		fall();
	}
	__except (EXCEPTION_EXECUTE_HANDLER)
	{
		memento();
	}
}

Мне лично не удалось заставить заработать __finally (поэтому я и написал __except с кодом проверки, который всегда работает), но это, возможно, кривизна моих рук.

Данная методика, при всей ее привлекательности, имеет ряд минусов:

• Один компилятор. Одна ОС. Не «чистый С++». Если Вы хотите работать без средств MS — Вы не сможете использовать эту методику
• Один поток — одна таблица. Если Вы напишете конструкцию из __try… __except, внутри __try запустите другой поток и, не выходя из __try второй поток вызовет segfault, то… ничего не произойдет, программа упадет «как обычно». Потому, что на каждый поток нужно писать отдельный обработчик SEH.

Минусов оказалось настолько много, что приходится искать второе решение.

Способ 2: POSIX — сигналы

Способ рассчитан на то, что в момент падения программа получает POSIX-сообщение SIGSEGV. Это безусловно так во всех UNIX-системах, но это фактически так (хотя никто не гарантировал, windows — не posix-совместима) и в windows тоже.

Методика простая — мы должны написать обработчик сообщения SIGSEGV, в котором программа совершит «прощальные действия» и, наконец, упадет:

void posix_death_signal(int signum)
{
	memento(); // прощальные действия
        signal(signum, SIG_DFL); // перепосылка сигнала
	exit(3); //выход из программы. Если не сделать этого, то обработчик будет вызываться бесконечно.
}

после чего мы должны зарегистрировать этот обработчик:

signal(SIGSEGV, posix_death_signal);

Вот готовый пример:

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


int memento()
{
	int a=0;
	MessageBoxA(NULL,"Memento mori","POSIX Signal",NULL);
	return 0;
}
void fall()
{
	  int* p = 0x00000000; 
	  *p = 13;
}
void posix_death_signal(int signum)
{
	memento();
	signal(signum, SIG_DFL);
	exit(3);
}


int main(int argc, char *argv[])
{
	signal(SIGSEGV, posix_death_signal);
	fall();
}

В отличие от SEH, это работает всегда: решение «многопоточное» (вы можете уронить программу в любом потоке, обработчик запустится в любом случае) и «кроссплатформенное» — работает под любым компилятором, и под любой POSIX-совместимой ОС.

Добрый вечер!
Проект нормально компилится в Qt, хочу запустить в режиме отладки, при запуске получаю следующее:

Приложение остановлено, так как оно получило сигнал от операционной системы.
Сигнал: SIGSEGV
Назначение: Segmentation fault.

При этом в VS2005 все нормально в режиме отладки.
В чем может быть причина?

Здравствуйте, Аноним, Вы писали:

А>Добрый вечер!
А>Проект нормально компилится в Qt, хочу запустить в режиме отладки, при запуске получаю следующее:

А>Приложение остановлено, так как оно получило сигнал от операционной системы.
А>Сигнал: SIGSEGV
А>Назначение: Segmentation fault.

А>При этом в VS2005 все нормально в режиме отладки.
А>В чем может быть причина?

Сегфолт любит вылазить при проблемах с подключаемыми dll (проверьте версии самих qt-библиотек и MSVCRT). А вообще, можно попробовать детальнее посмотреть дебаггером место сегфолта.

Здравствуйте, Аноним, Вы писали:

А>Добрый вечер!
А>Проект нормально компилится в Qt, хочу запустить в режиме отладки, при запуске получаю следующее:

А>Приложение остановлено, так как оно получило сигнал от операционной системы.
А>Сигнал: SIGSEGV
А>Назначение: Segmentation fault.

wiki:Ошибка_сегментации

Ошибка сегментации (англ. Segmentation fault или сокращённо segfault) — ошибка программного обеспечения, возникающая при попытке обращения к недоступным для записи участкам памяти либо при попытке изменения памяти запрещённым способом.

А>При этом в VS2005 все нормально в режиме отладки.

Без разницы, если сборка официальная (например, с mingw), значит дело в программе. VS 2005 очень лояльна в этом плане, многое не запрещает, но это не значит, что программа написана правильно.

А>В чем может быть причина?

Мало информации, по аналогии «А у меня автомобиль не ездит, в чём может быть причина?»

Прочти википедию об ошибке сегментации. Запусти трассировку, если надо поставь точки прерывания, найди в какой строчке возникает ошибка. Она ведь не размыта, вот у тебя всё хорошо, следующий шаг, и segfault. Место определяется очень точно. И если не получится понять самостоятельно в чём там дело, тогда надо публиковать код. Но как бы общая идея сводится к тому, что твоя программа неправильно обращается к памяти. А там уже может быть всё что угодно, указатель на несуществующий объект, обращение не из того потока, и так далее.

Здравствуйте, velkin & romankr, Вы писали:

Хочу сразу сказать — приложение отлично работает собранное как в vs2005, так и в mingw. Точку останова ставлю сразу на первой строке в main. Я просто не пойму если ошибка сегментации — так программа вообще не должна работать!

V>Сегфолт любит вылазить при проблемах с подключаемыми dll (проверьте версии самих qt-библиотек и MSVCRT). А вообще, можно попробовать детальнее посмотреть дебаггером место сегфолта.

dll-не использую, «чистый» проект с++, слинковано с 5 стат.библиотеками, которые в свою очередь, также собраны mingw.

V>wiki:Ошибка_сегментации

читал — бегло ничего подобного нет.

А>>При этом в VS2005 все нормально в режиме отладки.

V>Без разницы, если сборка официальная (например, с mingw), значит дело в программе. VS 2005 очень лояльна в этом плане, многое не запрещает, но это не значит, что программа написана правильно.

программа 2-е сутки тестируется, лопатит тонну информации — без сбоев, а я ее в отладочной версии даже запустить не могу!

V>Мало информации, по аналогии «А у меня автомобиль не ездит, в чём может быть причина?»

согласен, я только пересел на Qt, вернее только пытаюсь. программа достаточно большая, даже не знаю, что выкладывать то

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

так я и не могу трассировку запустить!

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, velkin & romankr, Вы писали:

А>Хочу сразу сказать — приложение отлично работает собранное как в vs2005, так и в mingw. Точку останова ставлю сразу на первой строке в main. Я просто не пойму если ошибка сегментации — так программа вообще не должна работать!

Почему не должна, в некоторых случаях очень даже должна.

А>dll-не использую, «чистый» проект с++, слинковано с 5 стат.библиотеками, которые в свою очередь, также собраны mingw.

Посмотри соседнюю тему

Автор: velkin
Дата: 26.02.12

, там был вопрос, как собрать статическую версию Qt, да ещё чтобы были исключения. Включил флаг -exceptions в configure.exe, проект в дебаге сразу стал вылетать с segmentation fault, причём в релизе отрабатывал исключение за милую душу. Чтобы он и в дебаге с отладчиком нормально работал и отвязался от библиотеки mingwm10.dll, убрал -mthreads. Так что ещё неизвестно, как у тебя скомпилированы эти 5 библиотек вместе с Qt. Я потому и упомянул про официальную сборку, они в этом не косячат, и если вылетел segfault, то хотя бы об используемых библиотеках думать не надо, и можно сосредоточиться на багах своей программы.

Здравствуйте, Аноним, Вы писали:

А>так я и не могу трассировку запустить!

Ещё вспомнил, если не можешь запустить режим отладки, тогда последовательно отключай библиотеки и код их использующий. Или наоборот, проверь, вылетает ли у тебя чистый Qt в режиме отладки или нет, а потом добавляй библиотеки. Всё равно надо как-то определить на каком этапе происходит segfault.

Здравствуйте, Аноним, Вы писали:

А>Добрый вечер!
А>Проект нормально компилится в Qt, хочу запустить в режиме отладки, при запуске получаю следующее:

А>Приложение остановлено, так как оно получило сигнал от операционной системы.
А>Сигнал: SIGSEGV
А>Назначение: Segmentation fault.

А>При этом в VS2005 все нормально в режиме отладки.
А>В чем может быть причина?

Была похожая ситуация. Отладчик не стартовал, а сваливался и показывал ассемблерный код. Точное сообщение уже не помню (под Win XP дело было). Причина была в сервисе аудио-карты под названием HsMgr.exe. Запущен он как системный сервис и его удаление позволило отладчику работать. Программа была простой, никакого отношения к работе с аудио не имела. Вывалиливалась в режиме отладки сразу на старте.

…HsMgr.exe (32-bit) and HsMgr64.exe (64-bit) are services which provide the GX2.0 features. Under Vista, they also enable Direct sound 2D/3D/EAX for applications. So it is essential to have them running on your system. On older drivers, these files were named [CMGxMon.exe] and [CMGxMon64.exe]. Windows Vista tends to block some .EXE or .DLL files in ZIP files for security issues. This may cause program to stop responding, or Windows Vista may prompt you for permission to run these programs during boot up…

Здравствуйте, Steamus, Вы писали:

S>Здравствуйте, Аноним, Вы писали:
S>Была похожая ситуация. Отладчик не стартовал, а сваливался и показывал ассемблерный код. Точное сообщение уже не помню (под Win XP дело было). Причина была в сервисе аудио-карты под названием HsMgr.exe. Запущен он как системный сервис и его удаление позволило отладчику работать. Программа была простой, никакого отношения к работе с аудио не имела. Вывалиливалась в режиме отладки сразу на старте.

Под WinXP у меня Qt подобным образом отваливался из-за нового BitDefender’а, пришлось его снести. Думаю список нежелательных программ этим не ограничивается.