public inbox for linux-newbie@vger.kernel.org
 help / color / mirror / Atom feed
From: Jim Nelson <james4765@verizon.net>
To: Jim Nelson <james4765@verizon.net>
Cc: linux-newbie@vger.kernel.org
Subject: Re: debugging a Segmentation fault
Date: Thu, 07 Oct 2004 05:42:05 -0400	[thread overview]
Message-ID: <41650F6D.4080703@verizon.net> (raw)
In-Reply-To: <41650E01.1050504@verizon.net>

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

  reply	other threads:[~2004-10-07  9:42 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
2004-10-07  9:42     ` Jim Nelson [this message]
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=41650F6D.4080703@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox