Вход:  Пароль:  
FreeSource: Юмор/SegmentationFault ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Эта страница была перенесена на altlinux.org. Текст на freesource.info заморожен.

Subject: Re: [Comm] Segmentation fault
Date: Tue, 20 Dec 2005
From: spider <spider@lsi>
To: ALT Linux Community <community@lists>

> Segmentation fault – что это такое и как с этим бороться?

Обращение к тем участкам адресного пространства, которое не
отображено на реальную память, вызывает исключение процессора
SIGSEGV. Это происходит исключительно из-за небрежного
программирования. Чаще всего встречается при залезании за границу
запрошенного участка памяти, например, при обработке массивов.
Есть тулза в дистрибутиве ALM 2.4 — valgrind. Она позволяет оттрассировать
программу на предмет небрежного программирования.
Бороться в С с SIGSEGV очень просто:
— проверять в обязательном порядке возврат от *всех* системных вызовов;
— это же делать и для своих вызовов:
— аккуратно работать с памятью — каждому malloc() надо дать по free().
Никогда не вставайте из-за компьютера, если для каждого malloc() не
написан его free(), даже поссать не вставайте и даже гуще:-).
— если работаете с массивами, тщательно проверяйте работу на их краях под
отладчиком, записывайте адреса, которые Вы видите в отладчике на бумажку,
не ленитесь.
— есть дурная манера запустить наскоро собранную программу и получив
SIGSEGV лезть в отладчик — надо в обязательном порядке начать с отладчика
— в этом случае Вы можете не получить SIGSEGV совсем. Вспомним, как от
первого в жизни стакана водки или от первой цигарки нас валило на забор
и тошнило, так и с программированием — надо пересилить себя поначалу и
получать потом кайф по полной программе от работы под отладчиком.
— часто бывает, что под отладчиком все работает, а без него валится — это 100 %
вылет за границу массива, просто всегда есть запас от нуля до нескольких байт
сзади нашего массива, ведь аллокатор нам наливает округляя по машинное слово
в большую сторону, за счет чего можно и незаметить как последний байт залетел
за линию;
— используйте тулзы типа valgrind для контроля сформированного кода на предмет
состояния кучи — если какая либо библиотека имеет проблемы, что часто бывает,
используйте ее очень осторожно, а лучше найдите замену.
— пишите на С в стиле фортрана — не выпендривайтесь и не экономьте на нажатиях
клавиш. Не пишите if( (bits=malloc(...) )!=NULL). Разбейте это на внятные части, и напишите
каждую в своей строке. Не лепите в одну строку скобки, возвраты, брики — каждому
оператору по своей строчке.
— в каждой строке не более одного выражения или оператора — отладчик работает с
отдельными строками исходного кода, а не элементами языка, и Вы просто не сможете
остановиться там, где хотите.
— самое главное правило — ни кусочка кода, который бы Вы не прокачали через
отладчик.
— 2 опции -W -Walll — обязательны. Добейтесь абсолютно чистой компиляции.
— никогда не опускайте того, что язык С позволяет опустить — всегда все определяйте явно.
Особенно это важно для деклараций. Неявные возвраты — еще одна причина проблем.
Все определяйте явно и отдельно. Если у вас даже сотня целых, не перечисляйте
их за одним int, а запишите каждый в отдельной строке. Если это Вам трудно --
это просто у Вас плохой редактор.
— забудьте навсегда про оптимизацию — за всю историю компиляторов для C эта
фича работала без ошибок на PC только в Watcom и Top Speed?. Для gcc это вообще
не светит. Да и на PC с ее тремя все время занятыми регистрами оптимизация --
просто обман.


ссылки по теме:
http://www.bitwizard.nl/sig11/


Ссылок на эту страницу нет


 
Файлы [Скрыть файлы/форму]
Один комментарий. [Показать комментарии/форму]