From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <43A74747.9070200@lsi.bas-net.by> Date: Tue, 20 Dec 2005 01:50:31 +0200 From: spider User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ALT Linux Community Subject: Re: [Comm] Segmentation fault References: <43A76008.3000305@rambler.ru> In-Reply-To: <43A76008.3000305@rambler.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: community@lists.altlinux.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ALT Linux Community List-Id: ALT Linux Community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2005 23:51:19 -0000 Archived-At: List-Archive: List-Post: 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 с ее тремя все время занятыми регистрами оптимизация -- просто обман.