All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Nelson <james4765@verizon.net>
To: linux-newbie@vger.kernel.org
Subject: Re: debugging a Segmentation fault
Date: Thu, 07 Oct 2004 05:36:01 -0400	[thread overview]
Message-ID: <41650E01.1050504@verizon.net> (raw)
In-Reply-To: <5.1.0.14.1.20041007000122.0207f680@celine>

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.
-
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

  reply	other threads:[~2004-10-07  9:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.44.0410062117530.13932-100000@legolas.personal. engin.umich.edu>
2004-10-07  7:05 ` debugging a Segmentation fault Ray Olszewski
2004-10-07  9:36   ` Jim Nelson [this message]
2004-10-07  9:42     ` Jim Nelson
2004-10-07  6:43 Karthik Vishwanath

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41650E01.1050504@verizon.net \
    --to=james4765@verizon.net \
    --cc=linux-newbie@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.