enabling core dumps

not really answering your question, but I find it more useful to

 R -d gdb

or

 R -d gdb -f test.R

where test.R reproduces the bug in some minimal code. A variant is

 R -d valgrind -f test.R

if the memory problem is not easy to spot.

Thanks for your reply Martin

Yes, I have used that route before, I have also been playing with the
emacs "M-x
gdb" option as describe in the R FAQ. But having no first hand
expertience with
core dumps I am curious why you prefer the -d flag route. Perhaps I'm
wrong but
I thought examining a core dump enables you to backtrace from the moment
things
went wrong, this seems to be a useful trick to have...

... if you manage to enable the core dump option that is.

usually what happens is (# meant to be a comment char)

  % R -d gdb -f test.R
  gdb> run
  ...segfault happens, breaks into gdb
  gdb> bt # print the backtrace
  gdb> up # move up the stack, to get to 'your' frame
  gdb> l # show source listing, use -O0 compiler flag, see gdb> help dir
  gdb> print some_suspect_variable
  gdb> call Rf_PrintValue(some_suspect_sexp)
  gdb> break suspect_function
  gdb> run # restart script, but break at suspect_function

and so on, i.e., you've got all the info you need. A neat trick is to
leave gdb running, repair and R CMD SHLIB your C code, return to gdb and

  gdb> run

to restart the same script but using the new shared lib (possibly
preserving breakpoints and other debugging info you'd used in previous
sessions).

I'm a heavy emacs user but find it easier to stick with gdb from the
shell -- one less layer to get in the way, when I'm confused enough as
it is.

Martin

cheers
David

______________________________________________
R-devel at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel