gdb core dump
Thomas Lumley
thomas@biostat.washington.edu
Fri, 16 Oct 1998 08:56:22 -0700 (PDT)
On Fri, 16 Oct 1998, Paul Gilbert wrote:
> >>Just execute as
> >>R -d gdb
>
> The problem is that the segmentation faults do not happen in any reliable way,
> and usually they occur in batch scripts I use for testing. I was wondering if
> there is anyway, after they occur, to recover useful information from the core
> file that is generated?
>
> >>>In order for this to be as useful as possible you should do it before
> >>> make install
> >>>so that gdb can find the source files and display them for you.
>
> I'm confused. What do I do before make install?
>
make creates a working version of R locally, make install puts it in eg
/usr/local/, but without the source. Running the debugger on the local
version of R in the source tree can be more useful than running it on the
installed version. This may not be feasible in your set up, and it isn't
critical -- you can still get a stack trace of function calls.
You look at a core file in much the same way, by running gdb through R -d
gdb. The reason to do it that way is to get the environment variables
right.
gorn% R -d gdb
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.15.1 (sparc-sun-solaris2.5),
Copyright 1995 Free Software Foundation, Inc...
(gdb) core-file core
You can now type
(gdb) backtrace
to list the stack trace and find exactly where R was when it segfaulted.
-thomas
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._