[Rd] enabling core dumps

[Martin Morgan]

pleydell at supagro.inra.fr wrote:
>> 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