From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Nelson Subject: Re: debugging a Segmentation fault Date: Thu, 07 Oct 2004 05:42:05 -0400 Sender: linux-newbie-owner@vger.kernel.org Message-ID: <41650F6D.4080703@verizon.net> References: <5.1.0.14.1.20041007000122.0207f680@celine> <41650E01.1050504@verizon.net> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <41650E01.1050504@verizon.net> List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Jim Nelson Cc: linux-newbie@vger.kernel.org Jim Nelson wrote: > Ray Olszewski wrote: > >> At 02:43 AM 10/7/2004 -0400, Karthik Vishwanath wrote: >> >>> Hello, >>> >>> I develop a monte-carlo code written in standard C. I recently >>> decided to >>> "add features" to the previous stable version and now the code >>> aborts with >>> a Segmentation fault. I suspect the code is executing different >>> parts of >>> the code before crashing, on different runs (and therefore crashing at >>> different points?). There is no core dumped either. >>> >>> Can I discover which source-line caused the program to abort (or get >>> information about which function it was, etc.), or trap the signal >>> within the code and print out details -- how? >>> >>> Please excuse me if this post is off-topic for this list -- can some >>> one >>> please point me to a list where such questions are not, otherwise/as >>> well? >> >> >> >> The usual tools for debugging Linux/Unix C and C++ programs are gdb >> and strace. Do you need more specific direction than that? I haven't >> used gdb all the much myself, bu I have used strace to track down >> segfaults in the past ... messy output, hard to read, but tells you >> just about everything the program is doing. >> >> You do want to compile the program with debugging support in ... >> basically, that means maintaining the symbol table (not "stripping" >> the executable), which I believe is the default behavior of gcc anyway. >> > Best way to get gdb to work to its fullest extent is to use the gcc > flag -gdb3 (it compiles in a whole lot of debugging information, and > even allows you to single-step through the source code, set > conditional breakpoints, and much, much more). gdb is a little hard > to use at first, and if you have KDE, you might want to try kdbg - I > haven't used it much myself, though. That should have been -ggdb3 - I shouldn't write email before coffee... - To unsubscribe from this list: send the line "unsubscribe linux-newbie" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.linux-learn.org/faqs