debugging a Segmentation fault

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?


Thanks!

-K



-
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

Re: debugging a Segmentation fault

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.



-
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

Re: debugging a Segmentation fault

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

Re: debugging a Segmentation fault

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