Re: [Comm] Segmentation fault

[spider <spider@lsi.bas-net.by>]

Dmitry A. Kharitonov wrote:

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