|
 |
clipka <nomail@nomail> wrote:
> Warp <war### [at] tag povrayorg> wrote:
> > The most common, and also easiest, task for which gdb is very handy is
> > determining the exact point where a program crashes. You do it like this:
> > ...
> I'll give it a try next time I have a segfault or other crash to track down - I
> guess it will be faster that valgrind for that job :)
Have you ever wondered what the 'core' file is used for (ie. have you
ever wondered what the "core dumped" is all about)?
If you have your shell configured to dump core when a program crashes,
you can use the 'core' file in conjunction with gdb to do what I described
without having to run the program again. This can be useful if the program
crashing happens only randomly or it takes a very long time to happen.
I must admit, though, that I don't remember now how exactly the 'core'
file was used. It might have been that gdb automatically reads it if it
exists in the current directory (and has been produced by the program in
question, an information which is most probably included in the 'core' file
itself). So in effect if you have the 'core' file from the program crash,
you can skip the "run the program from gdb" part.
> Unfortunately, with debug information and no optimizations I don't see any crash
> (still hoping for something to pop up in valgrind during cleanup though; we're
> at 89% right now). But with a little luck it's the optimizations that make the
> error surface, not the absence of debug info, so there is still hope that it
> might get me somewhere.
You can try with optimizations and hope they still allow you to find
the location of the crash. Start with -O1 and try making it crash. Increase
from there if it doesn't seem to happen.
gdb will still report the location of the crash, but as I said, it might
be confused by the optimizations performed by the compiler (eg. because of
the compiler moving code around or inlining functions).
--
- Warp
Post a reply to this message
|
|
