One approach to debugging is to include print statements at various places to make sure your code has reached those points and to show current values of variables. Often this is sufficient, but sometimes more sophisticated tools are useful.
-g
flag.gdb
.ddd
.valgrind
. valgrind
is available on the Linux workstations.traceback()
will print the call stack for the most recent error. This can help you narrow down where the error was raised.debug(fun)
and undebug(fun)
turn debugging of fun
on and off. When debugging is on, each call to fun
enters the debugger.trace(fun)
and untrace(fun)
turn tracing of fun
on and off. When a function is traced, some information is printed on each call. An experimental more advanced form of trace
can do more things.browser()
calls can be placed in a function to enter the debugger at selected points.fix(fun)
provides a quick way to edit a function. Using a separate text editor may be more convenient.options(error=recover)
will cause R to enter the debugger when an error is signaled.debug
package available from CRAN may also be useful.-d
flag: For example, R -d gdb
will use gdb
.Sometimes it is necessary to signal or trap errors in R.
stop
function is used to signal errors in R code.error
function.error
option; details are given in the help for options
.tryCatch
, withCallingHandlers
and signalCondition
.Once code is running you may want to see if you can make it run faster. Profiling can help.
perf
.valgrind
can also be used for profiling.Rprof
.