gdb core dump

[Thomas Lumley]

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