pleyd...@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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel