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.