From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2982 invoked by alias); 25 Mar 2010 11:45:46 -0000 Received: (qmail 2971 invoked by uid 22791); 25 Mar 2010 11:45:44 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_50 X-Spam-Check-By: sourceware.org Received: from exprod6og111.obsmtp.com (HELO exprod6og111.obsmtp.com) (64.18.1.27) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 25 Mar 2010 11:45:36 +0000 Received: from source ([192.150.8.22]) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKS6tM3E4DP///pPem2ksLdJXsG4lxgwpK@postini.com; Thu, 25 Mar 2010 04:45:35 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id o2PBjPs5029729; Thu, 25 Mar 2010 04:45:26 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id o2PBjO7o010305; Thu, 25 Mar 2010 04:45:24 -0700 (PDT) Received: from excas02.corp.adobe.com (10.8.188.212) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 25 Mar 2010 04:45:23 -0700 Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by excas02.corp.adobe.com ([10.8.188.212]) with mapi; Thu, 25 Mar 2010 04:45:23 -0700 From: "John (Eljay) Love-Jensen" To: beamendsltd , "gcc-help@gcc.gnu.org" Date: Thu, 25 Mar 2010 14:33:00 -0000 Subject: RE: Segmentation fault Message-ID: <4B7A6CC9992C4E4FB188D02872C90A6B8A0141BA@nambxv01a.corp.adobe.com> References: <1269516508.7204.9.camel@beamends-1> In-Reply-To: <1269516508.7204.9.camel@beamends-1> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2010-03/txt/msg00289.txt.bz2 Hi Richard, Segmentation faults are usually one of the easiest bugs to track down. At = least at the point of failure. 1. Compile your program with debug information: # gcc -g -o MyApp MyCode.c 2. Run your program in the debugger: # gdb ./MyApp (gdb) run 3. When your program crashes, look at the stack backtrace: (gdb) bt The first few frames will give you the context of the crash, at the point o= f failure. If the cause of the failure is distant in time/space from the point of fail= ure, that can be trickier to figure out. If the crash is hard to reproduce consistently, that may make things tricki= er to figure out. For bug classification, here are some amusing (yet surprisingly useful) typ= es of bugs: http://en.wikipedia.org/wiki/Heisenbug And here are some more, and a recap of the above: http://catb.org/jargon/html/S/smash-the-stack.html http://catb.org/jargon/html/B/buffer-overflow.html http://catb.org/jargon/html/A/aliasing-bug.html http://catb.org/jargon/html/F/fandango-on-core.html http://catb.org/jargon/html/M/memory-leak.html http://catb.org/jargon/html/M/memory-smash.html http://catb.org/jargon/html/O/overrun-screw.html http://catb.org/jargon/html/S/secondary-damage.html http://catb.org/jargon/html/H/heisenbug.html http://catb.org/jargon/html/B/Bohr-bug.html http://catb.org/jargon/html/M/mandelbug.html http://catb.org/jargon/html/S/schroedinbug.html Sincerely, --Eljay