|
Home > Archive > Unix Programming > May 2005 > Newbie question: how to get the stack trace from a dump file
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Newbie question: how to get the stack trace from a dump file
|
|
| usgog@yahoo.com 2005-05-17, 5:57 pm |
| I am a newbie to Linux and just got a core dump file for my program.
The error is segmentation fault. So how to get the stack trace out of
the dump file? I used gdb -> 'core-file mycorefile' -> 'where' and it
returns 'Can't access memory at address 0x...'. Do I need any other
files for gdb to output the stack trace? Please advise.
| |
| Loic Domaigne 2005-05-17, 5:57 pm |
| Hello,
> I am a newbie to Linux and just got a core dump file for my program.
> The error is segmentation fault. So how to get the stack trace out of
> the dump file? I used gdb -> 'core-file mycorefile' -> 'where' and it
> returns 'Can't access memory at address 0x...'. Do I need any other
> files for gdb to output the stack trace? Please advise.
Compile your program with the flag -g (debugging symbols)
Run then gdb as follows:
bash$ gdb name_of_your_binary name_of_your_core
and then type 'where', followed eventually by the command 'bt' if the
command 'where' wasn't explicit enough.
Cheers,
Loic.
| |
| Paul Pluzhnikov 2005-05-17, 5:57 pm |
| usgog@yahoo.com writes:
> Do I need any other
> files for gdb to output the stack trace?
No.
Some versions of gdb have difficulties with core files on some
platforms, especially if the executable is multithreaded.
Try running your program under gdb from the start, or try a different
version of gdb.
If neither of the above helps, tell us what platform you are on,
what version of gdb you are using. Some details about the app may
come in handy as well.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| Paul Pluzhnikov 2005-05-17, 5:57 pm |
| Loic Domaigne <loic-dev@gmx.net> writes:
> Run then gdb as follows:
> bash$ gdb name_of_your_binary name_of_your_core
This is exactly equivalent to:
gdb name_of_your_binary
(gdb) core name_of_your_core
which is what OP has apparently already done.
> and then type 'where', followed eventually by the command 'bt' if the
> command 'where' wasn't explicit enough.
The 'where' and 'bt' are exact synonyms.
Are you saying they sometimes produce different output?
Could you perhaps demonstrate that?
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| Måns Rullgård 2005-05-17, 5:57 pm |
| Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> writes:
> usgog@yahoo.com writes:
>
>
> No.
>
> Some versions of gdb have difficulties with core files on some
> platforms, especially if the executable is multithreaded.
>
> Try running your program under gdb from the start, or try a different
> version of gdb.
In my experience, gdb more often has problems running a multithreaded
program than examining a core dump from one.
--
Måns Rullgård
mru@inprovide.com
| |
| David Schwartz 2005-05-17, 8:48 pm |
|
"Måns Rullgård" <mru@inprovide.com> wrote in message
news:yw1xy8admooa.fsf@ford.inprovide.com...
> Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> writes:
[vbcol=seagreen]
> In my experience, gdb more often has problems running a multithreaded
> program than examining a core dump from one.
And you can always catch SIGBUS, SIGSEFV, SIGILL, SIGFPE and in the
handler, call 'fork' and then 'abort' in the child. On some operating
systems, you may need to invoke the 'fork' system call directly as it may
otherwise be unsafe to call 'fork' in a signal handler.
This breaks some rules, but it may work for you. And, obviously, once
you've encountered a fatal signal, you can't keep going anyway.
DS
| |
| David Resnick 2005-05-18, 7:53 am |
|
Paul Pluzhnikov wrote:
> Loic Domaigne <loic-dev@gmx.net> writes:
>
>
> This is exactly equivalent to:
>
> gdb name_of_your_binary
> (gdb) core name_of_your_core
>
> which is what OP has apparently already done.
>
Nope. Looking at OP's message, he said
[vbcol=seagreen]
Looks like he invoked gdb without indicating
the binary name and that was his issue.
-David
| |
| loic-dev@gmx.net 2005-05-19, 7:48 am |
| Salut Paul,
the[vbcol=seagreen]
>
> The 'where' and 'bt' are exact synonyms.
> Are you saying they sometimes produce different output?
> Could you perhaps demonstrate that?
In my mind, 'where' wouldn't show the stack trace. But I've been
mistaken.
Loic.
|
|
|
|
|