General suggestions for debugging in R

Question

I get an error when using an R function that I wrote:

Warning messages:
1: glm.fit: algorithm did not converge 
2: glm.fit: algorithm did not converge 


        

Answer 1

Mark Bravington's debugger which is available as the package debug on CRAN is very good and pretty straight forward.

library(debug);
mtrace(myfunction);
myfunction(a,b);
#... debugging, can query objects, step, skip, run, breakpoints etc..
qqq(); # quit the debugger only
mtrace.off(); # turn off debugging

The code pops up in a highlighted Tk window so you can see what's going on and, of course you can call another mtrace() while in a different function.

HTH

Answer 2

I'd say that debugging is an art form, so there's no clear silver bullet. There are good strategies for debugging in any language, and they apply here too (e.g. read this nice article). For instance, the first thing is to reproduce the problem...if you can't do that, then you need to get more information (e.g. with logging). Once you can reproduce it, you need to reduce it down to the source.

Rather than a "trick", I would say that I have a favorite debugging routine:

1. When an error occurs, the first thing that I usually do is look at the stack trace by calling traceback(): that shows you where the error occurred, which is especially useful if you have several nested functions.
2. Next I will set options(error=recover); this immediately switches into browser mode where the error occurs, so you can browse the workspace from there.
3. If I still don't have enough information, I usually use the debug() function and step through the script line by line.

The best new trick in R 2.10 (when working with script files) is to use the findLineNum() and setBreakpoint() functions.

As a final comment: depending upon the error, it is also very helpful to set try() or tryCatch() statements around external function calls (especially when dealing with S4 classes). That will sometimes provide even more information, and it also gives you more control over how errors are handled at run time.

These related questions have a lot of suggestions:

• Debugging tools for the R language
• Debugging lapply/sapply calls
• Getting the state of variables after an error occurs in R
• R script line numbers at error?

Answer 3

The best walkthrough I've seen so far is:

http://www.biostat.jhsph.edu/%7Erpeng/docs/R-debug-tools.pdf

Anybody agree/disagree?

Answer 4

My general strategy looks like:

1. Run traceback() to see look for obvious issues
2. Set options(warn=2) to treat warnings like errors
3. Set options(error=recover) to step into the call stack on error

Answer 5

After going through all the steps suggested here I just learned that setting .verbose = TRUE in foreach() also gives me tons of useful information. In particular foreach(.verbose=TRUE) shows exactly where an error occurs inside the foreach loop, while traceback() does not look inside the foreach loop.

Answer 6

Based on the answer I received here, you should definitely check out the options(error=recover) setting. When this is set, upon encountering an error, you'll see text on the console similar to the following (traceback output):

> source(<my filename>)
Error in plot.window(...) : need finite 'xlim' values
In addition: Warning messages:
1: In xy.coords(x, y, xlabel, ylabel, log) : NAs introduced by coercion
2: In min(x) : no non-missing arguments to min; returning Inf
3: In max(x) : no non-missing arguments to max; returning -Inf

Enter a frame number, or 0 to exit   

1: source(<my filename>)
2: eval.with.vis(ei, envir)
3: eval.with.vis(expr, envir, enclos)
4: LinearParamSearch(data = dataset, y = data.frame(LGD = dataset$LGD10), data.names = data
5: LinearParamSearch.R#66: plot(x = x, y = y.data, xlab = names(y), ylab = data.names[i])
6: LinearParamSearch.R#66: plot.default(x = x, y = y.data, xlab = names(y), ylab = data.nam
7: LinearParamSearch.R#66: localWindow(xlim, ylim, log, asp, ...)
8: LinearParamSearch.R#66: plot.window(...)

Selection:

At which point you can choose which "frame" to enter. When you make a selection, you'll be placed into browser() mode:

Selection: 4
Called from: stop(gettextf("replacement has %d rows, data has %d", N, n), 
    domain = NA)
Browse[1]> 

And you can examine the environment as it was at the time of the error. When you're done, type c to bring you back to the frame selection menu. When you're done, as it tells you, type 0 to exit.