the core

the core

Post by Joe Sys » Tue, 22 Jul 1997 04:00:00



I have a nice little segmentation-fault in the program i am currently
developing. I get a core-dump, as i have gotten lots of times in the past.
Only now i can't figure out what is wrong on my own, so i would like to
investigate this core for further information.

Question is: What does this core contain? Saved registers of the computer
when it hung? Or maybe some c-code (doubtful)? Which program should i use
to investigate the core?

Thanks in advance, and please cc to the reply adress.

/Joe

 
 
 

the core

Post by Richar » Tue, 22 Jul 1997 04:00:00


Your core dump is most likely caused by you writing or accessing memory,
probably with a pointer, that does not belong to your process.

The easiest way to debug this, IMHO, is to sprinkle printfs throughout
the code followed by getchar's to pause the code until you press a key.
You need to isolate which code line is causing your seg-fault. Once you
find it then comment it out, recompile and run. Of course your program
will only partialy work but hopefully without the core dump. I have
found that isolating the suspect code is most of the work.

Hope this helps, if it does not and you can partialy document your
efforts examining a core file I for one would be interested in reading
it. Please post.

The message that prompted this reply was:

Quote:> I have a nice little segmentation-fault in the program i am currently
> developing. I get a core-dump, as i have gotten lots of times in the past.
> Only now i can't figure out what is wrong on my own, so i would like to
> investigate this core for further information.

> Question is: What does this core contain? Saved registers of the computer
> when it hung? Or maybe some c-code (doubtful)? Which program should i use
> to investigate the core?

> Thanks in advance, and please cc to the reply adress.

> /Joe


 
 
 

the core

Post by Alan Shutk » Tue, 22 Jul 1997 04:00:00


Richard> The easiest way to debug this, IMHO, is to sprinkle printfs
Richard> throughout the code followed by getchar's to pause the code
Richard> until you press a key.

Actually, the core file provides an easier way.

gdb myprogram core

will start gdb up and cause it to load the core file.  You can type
'bt' to get a traceback and see where the core happenned.  You can use
'up' and 'down' to travel through the stack frames and look at
arguments, variables, etc.

(FWIW, the core contains the process's memory image at the time it
died.)

--

Having a wonderful wine, wish you were beer.

 
 
 

the core

Post by David Z. Ma » Tue, 22 Jul 1997 04:00:00



JS> I have a nice little segmentation-fault in the program i am currently
JS> developing. I get a core-dump, as i have gotten lots of times in the past.
JS> Only now i can't figure out what is wrong on my own, so i would like to
JS> investigate this core for further information.
JS>
JS> Question is: What does this core contain? Saved registers of the computer
JS> when it hung? Or maybe some c-code (doubtful)? Which program should i use
JS> to investigate the core?

Are you compiling with debug information (cc -g)?  If so, you can use
the core file with gdb (gdb myprog core).  This will show you the
state of the program when it crashed, tell you why it crashed ("caught
signal SIGSEGV" or some such thing) and let you examine the state
using the "print", "info vars", "bt", "up", and "down" commands.
Looking at the gdb documentation (in Info) might be a good idea.

--
 _____________________________
/                             \  "We can write all we know in 4 lines."
|          David Maze         |   -- Ray Ashoori, MIT Physics Professor

| http://donut.mit.edu/dmaze/ |        IHTFP         17 Yellow Pigs
\_____________________________/     ...the Institute is your friend...

 
 
 

the core

Post by david parso » Tue, 22 Jul 1997 04:00:00



>Your core dump is most likely caused by you writing or accessing memory,
>probably with a pointer, that does not belong to your process.

>The easiest way to debug this, IMHO, is to sprinkle printfs throughout
>the code followed by getchar's to pause the code until you press a key.

   It depends.  There are some cases when this works, and there are some
   cases where it doesn't.  Generally, things like this can be solved
   with the use of gdb (or any other source de*;  I mention gdb
   because if it's not the only one on the Linux platform, it's by far
   the most widely used), and you don't want to build herds of printfs
   until you reach a situation where gdb just doesn't work (the program
   being too big for gdb[1], gdb not having enough smarts to look for
   what you need to find, or the existance of the debugging code
   getting rid of the bug.)

                    ____
      david parsons \bi/ Printf is awfully intrusive for debugging.
                     \/

   [1 I tried to debug a bizarre i/o crash in a quantum chemistry
      program with gdb.  this crash would only happen after pushing
      several gigabytes to and from a fortran unit, and I managed to
      track it down to corruption in the file descriptor table in
      the fortran library.  So then I set a watchpoint on the table
      and started to run the program.  Bad Idea;  I only had 64mb of
      real memory and 256mb of swap, and gdb et every last byte of
      it and hung the system up like a drum.]

 
 
 

the core

Post by John Loone » Fri, 25 Jul 1997 04:00:00



> Question is: What does this core contain? Saved registers of the computer
> when it hung? Or maybe some c-code (doubtful)? Which program should i use
> to investigate the core?

 The graphical front end to GDB called DDD" is worth a look, it's
very nice, and is very easy to use, compared to GDB. All nice and
motiffy!

Kate

--
 "I am Grey. I stand between the candle and the star.
    We are Grey. We stand between the darkness and the light."

Delete .nospam from my return address for a reply-to

 
 
 

the core

Post by Tom Dale » Thu, 31 Jul 1997 04:00:00



> I have a nice little segmentation-fault in the program i am currently
> developing. I get a core-dump, as i have gotten lots of times in the past.
> Only now i can't figure out what is wrong on my own, so i would like to
> investigate this core for further information.

> Question is: What does this core contain? Saved registers of the computer
> when it hung? Or maybe some c-code (doubtful)? Which program should i use
> to investigate the core?

> Thanks in advance, and please cc to the reply adress.

> /Joe

You can use gdb to look at the core file.  If you compile your code
with the -g option the dump will even shod you line numbers.
If your program is called "foo" you would run gdb like this:

$ gdb foo core

When you get to the command prompt type "where" and it will show you
a stack trace of where the program was when it died.  This is usually
enough for me to trouble shoot a segmentation-fault.

Type "quit" at the command prompt to exit the de*.


 
 
 

1. Get "Segmentation fault (core dumped)" but no core file found

On our Solaris, when a program has a segmentation fault, it crashes and
prints out the message "Segmentation fault (core dumped)" but the core file
is somehow not written to the disk and cannot be found afterwards. Does
anybody has similar experience? How can I fix this problem?

--
-------------------------------------------------------------------------------

2. HORRIBLE swapping performance (1.1.48)

3. Apache problem - core dumps (httpd.core) all over the place

4. Optimum linux network configuration

5. Mysterious core file from "CORE"

6. color-xterm from Redhat 4.0 brain-damage

7. XF86_SVGA core dumped, but where is the core file?

8. kde 2.2.2

9. Strange SSH halting problem between Fedora Core 2/Fedora Core 3

10. dump core or not dump core

11. why are core dumps always named "core"?

12. core dumps core dumps everywhere...

13. To core or not to core - Part 2