Приложение остановлено так как получен сигнал от операционной системы

[Dez]

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

описание гласит:

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

В зависимости от изменений в коде - строка на которую выпадает такая ошибка может быть разной.
Проблема в том что приложение не может корректно выйти удалив все объекты.
Так же ошибка не связана с ошибками с С++ коде, все указатели валидны, и других ошибок на первый взгляд не видно.
Если проходить отладчиком код - то ошибка так же возникает в произвольных строках, но чаще всего примерно в одной.
Вопрос - какие могут быть причины такой ошибки ?

пример кода

Код: [Выделить]

/*/////////////////////////////////////////////////////////////////*/
void OgreOggSoundManager::_releaseAll()
{
// Destroy all sounds
SoundMap::iterator i = mSoundMap.begin();
while(i != mSoundMap.end())
{
#if OGGSOUND_THREADED
// Set flag
mNoLock = true;
#endif
Ogre::SceneManager*s = i->second->getSceneManager();  //(1)
s->destroyMovableObject(i->second->getName(), OgreOggSoundFactory::FACTORY_TYPE_NAME); //(2)

#if OGGSOUND_THREADED
// Set flag
mNoLock = true;
#endif
++i;
}


ошибки возникают или в строке (1) или в строке (2)

[wl]

Из приведенного текста ничего сказать нельзя.
Попробуйте ее под valgrind-ом погонять - и memcheck, и drd.
Попробуйте включить отладочную информацию и проанализировать core в gdb.

[Dez]

Попробую воспользоваться вашими советами, хотя не вижу пока что как они помогут.
GDB вполне нормально показывает отладочную информацию (это видно хотябы на приатаченом в архиве скриншоте ).
Что именно вы имеете в виду под "проанализировать core в gdb" ?

Собственно сюда я пишу в силу странности ошибки, т.е. возможно есть какие-то требования по времени выхода приложения, или еще что-то такое ?
так как складывается впечатление что пропадает доступ к памяти которую еще не удаляли.
Пользователь решил продолжить мысль 08 Июля 2010, 14:03:37:Ошибка судя по всему примерно локализована и заключается в различном поведении OpenAL библиотеки под разными платформами.
будем исправлять.

[VestniK]

Когда сегфолт происходит в случайном месте в коде это почти явное указание на memory corruption. Где-то когда-то произошло модифицирование памяти которая по идее приложению не пренадлежит (например выход за границу массива в динамичекой памяти), но почему-то сам факт обращения к этому участку памяти сегфолт не вызвал. Тут лучше всего не gdb а valgrind использовать.

Я когда впервые с таким столкнулся 2 недели с gdb развлекался и читал в гугле предложение использовать valgrind, а когда попробовал оный, то через 5 минут нашёл и исправил ошибку.

[wl]

Что именно вы имеете в виду под "проанализировать core в gdb" ?

Когда приложение так разваливается, операционная система сваливает в файл содержимое памяти.
Файл называется обычно core или core.<pid>, где <pid> - номер процесса, или <имя_исполняемого_файла>.core
В убунте это просто core.
Его можно загрузить в gdb и посмотреть значения переменных, стек вызовов и пр.
Если при компиляции была включена отладочная информация (-ggdb3), то дебагер подгрузит исходники и покажет имена функций в стеке и номера строк, на которых остановилось выполнение.

Далее, максимальный размер этого файла задается в ulimit. Этот размер по умолчанию 0 - т.е. файл не создается.
Снять лимит с размера core можно командой

Код: [Выделить]

ulimit -c unlimited
Поскольку у вас все в IDE, то ищите стеки там. Кстати, что за среда такая красивая?

Собственно сюда я пишу в силу странности ошибки, т.е. возможно есть какие-то требования по времени выхода приложения, или еще что-то такое ?
так как складывается впечатление что пропадает доступ к памяти которую еще не удаляли.

По-моему, наоборот, попытка писать в память, которую уже освободили, или double-free, или выход за границы.
Или какая-то чехарда с указателями и преобразованиями типов, т.к. это С++.
Это, конечно, некрасиво, но при выходе память можно вообще не освобождать - система все сама очень аккуратно подчистит.

Если приложение многопоточное, то есть такая неприятная штука race conditions. Тоже хрен отловишь.

Ошибка судя по всему примерно локализована и заключается в различном поведении OpenAL библиотеки под разными платформами.

Вполне возможно.

Я еще раз рекомендую - попробуйте valgrind.
Лучшего инструмента для отлова ошибок при работе с памятью и потоками Вы не найдете.

Когда сегфолт происходит в случайном месте в коде это почти явное указание на memory corruption. Где-то когда-то произошло модифицирование памяти которая по идее приложению не пренадлежит (например выход за границу массива в динамичекой памяти)

Во-во. И когда конкретно это произошло, сказать сложно. Может быть, вот только что, а может быть, вообще при старте программы.

[Dez]

Благодарю за рекомендации, буду пробовать.

Кратко отвечу на вопросы
1) Среда разработки - QTCreator
2) Ошибка походу таки в рейс кондишин - а именно удаляются звуки а какой-то поток продолжает к ним обращаться (походу проблема врапера вокруг OpenAL), в котором толи не реализована корректная остановка то ли реализована с ошибкой (благо либа OpenSource).
3) Спасибо за инфу по особенностям GDB и ключам ))) ранее работал только с MS VC
Как пофиксим - сообщу что и как, для удовлетворения интереса (если кому-то интересно)

[wl]

3) Спасибо за инфу по особенностям GDB и ключам ))) ранее работал только с MS VC

MS VC как IDE довольно далеко опережает все линуксовое.
Но аналогов valgrind под виндой нет.

[sciko]

MS VC как IDE довольно далеко опережает все линуксовое.

Так может говорить только человек который не работал в emacs или vim.