Home > Archive > Unix Programming > November 2005 > Analysing core files
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 |
Analysing core files
|
|
|
| Hi,
I know we can use a debugger to see some details about a core file.I
do a strings on the core file and it prints a lot of information,though
the debugger only shows limited relevant information.
I have a long running program so its difficult to attach to the program
and I even dont know at what point its crashing.Also in the debugger it
shows up as a corrupt stack, like below :
#3 0x20000000017ab4f0 in __pthread_sighandler_rt () from
/lib/libpthread.so.0
#4 <signal handler called>
Previous frame inner to this frame (corrupt stack?)
I was thinking if I can make use of some the details present in the core
file which the debugger dosent inform.
Can anyone help in digging out the wealth of information being left
hidden inside the core file ?
PS: Platform is Linux.
TIA
~
| |
| Rich Teer 2005-11-24, 6:58 pm |
| On Thu, 24 Nov 2005, grid wrote:
> I have a long running program so its difficult to attach to the program and I
Huh? With dbx you just put the PID on the command line.
> PS: Platform is Linux.
Ahh. You might find the debugging tools available on Solaris to
be more useful.
--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
| |
| Paul Pluzhnikov 2005-11-24, 6:58 pm |
| grid <prohit99@gmail.com> writes:
> I have a long running program so its difficult to attach to the
> program
Why? How long the program runs has absolutely nothing to do with
attaching a debugger to it.
> and I even dont know at what point its crashing.Also in the
> debugger it shows up as a corrupt stack, like below :
If your program truly corrupts stack, running the program with the
debugger attached may or may not give you more info.
You should also try different version(s) of 'gdb' -- I have seen
cases where gdb-5.3 would produce correct backtrace where gdb-6.0
wouldn't (though not on Linux/x86_64).
> I was thinking if I can make use of some the details present in the
> core file which the debugger dosent inform.
There are details in the core file which an expert might be able
to extract. Unfortunately, you'll need to observe the expert doing
it to find out how it's done :)
Begin by doing 'x/80x $rsp' at the (gdb) prompt (but it's unlikely
you'll be able to interpret what you'll see :(
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| joe@invalid.address 2005-11-24, 6:58 pm |
| Rich Teer <rich.teer@rite-group.com> writes:
> On Thu, 24 Nov 2005, grid wrote:
>
>
> Huh? With dbx you just put the PID on the command line.
>
>
> Ahh. You might find the debugging tools available on Solaris to
> be more useful.
The debugging tools available on Solaris work on Linux?
Joe
--
Gort, klatu barada nikto
| |
| Rich Teer 2005-11-24, 6:58 pm |
| On Thu, 24 Nov 2005, joe@invalid.address wrote:
> The debugging tools available on Solaris work on Linux?
Not necessarily. What I was suggesting to the OP is that maybe
Solaris would be a better development environment--provided, of
course, the app is not fraught with Linuxisms.
--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
| |
| joe@invalid.address 2005-11-24, 6:58 pm |
| Rich Teer <rich.teer@rite-group.com> writes:
> On Thu, 24 Nov 2005, joe@invalid.address wrote:
>
>
> Not necessarily. What I was suggesting to the OP is that maybe
> Solaris would be a better development environment--provided, of
> course, the app is not fraught with Linuxisms.
Well, I knew that's what you were suggesting, but that's like saying
"use emacs" when someone asks how to do something in vi.
Anyway, happy Thanksgiving (do you guys do that north of the border?)
Joe
--
Gort, klatu barada nikto
| |
| Rich Teer 2005-11-24, 6:58 pm |
| On Thu, 24 Nov 2005, joe@invalid.address wrote:
> Well, I knew that's what you were suggesting, but that's like saying
> "use emacs" when someone asks how to do something in vi.
I prefer to liken it to the Doctor sketch:
Patient: Doctor, it hurts when I do foo.
Doctor: Well, don't do that then!
> Anyway, happy Thanksgiving (do you guys do that north of the border?)
And to you. Yes, we do Thanksgiving here, but at a different time.
Ours is in October, and I have no idea why they're different.
--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
| |
| clayne 2005-11-24, 6:58 pm |
|
Rich, there is definitely one exception to this rule (Solaris before
Linux):
Valgrind.
I personally would much rather use Solaris for all of my development,
and for the most
part I usually do (Sol8/9) - but for certain profiling or deeper memory
debugging, you cannot beat Valgrind - which is only natively available
on Linux i86 platforms.
On another note I've also found Darwin to be quite the bastard about
correct coding (from a runtime perspective) which helps out when you're
trying to double check why something may work on say, Linux, but not on
other platforms. The greater issue here being that Linux is too
programmer-friendly - creating lazy code.
Rich Teer wrote:
> On Thu, 24 Nov 2005, joe@invalid.address wrote:
>
>
> Not necessarily. What I was suggesting to the OP is that maybe
> Solaris would be a better development environment--provided, of
> course, the app is not fraught with Linuxisms.
| |
| Thomas Maier-Komor 2005-11-25, 7:57 am |
| clayne wrote:
> Rich, there is definitely one exception to this rule (Solaris before
> Linux):
>
> Valgrind.
>
personally, I prefer libumem of Solaris by far over valgrind. But that's
just my personal opinion. Test it yourself - it is much faster and I
think even more accurate...
Tom
| |
| Argus225 2005-11-26, 3:58 am |
| I suggest you running your program with valgrind. In fact your
segmentation fault can arrive much later after the faulty instruction.
| |
| Markus Elfring 2005-11-26, 9:56 pm |
| > Can anyone help in digging out the wealth of information being left
> hidden inside the core file ?
Does this article provide informations that are useful for you?
http://en.wikipedia.org/wiki/Core_dump
Regards,
Markus
|
|
|
|
|