Very Computer

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

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

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.

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...

                    ____
      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.]

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

$ 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*.