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

As was pointed out to me in another question, Rprof() and summaryRprof() are nice tools to find slow parts of your program that might benefit from speeding up or moving to a C/C++ implementation. This probably applies more if you're doing simulation work or other compute- or data-intensive activities. The profr package can help visualizing the results.

I'm on a bit of a learn-about-debugging kick, so another suggestion from another thread:

• Set options(warn=2) to treat warnings like errors

You can also use options to drop you right into the heat of the action when an error or warning occurs, using your favorite debugging function of choice. For instance:

• Set options(error=recover) to run recover() when an error occurs, as Shane noted (and as is documented in the R debugging guide. Or any other handy function you would find useful to have run.

And another two methods from one of @Shane's links:

• Wrap an inner function call with try() to return more information on it.
• For *apply functions, use .inform=TRUE (from the plyr package) as an option to the apply command

@JoshuaUlrich also pointed out a neat way of using the conditional abilities of the classic browser() command to turn on/off debugging:

• Put inside the function you might want to debug browser(expr=isTRUE(getOption("myDebug")))
• And set the global option by options(myDebug=TRUE)
• You could even wrap the browser call: myBrowse <- browser(expr=isTRUE(getOption("myDebug"))) and then call with myBrowse() since it uses globals.

Then there are the new functions available in R 2.10:

• findLineNum() takes a source file name and line number and returns the function and environment. This seems to be helpful when you source() a .R file and it returns an error at line #n, but you need to know what function is located at line #n.
• setBreakpoint() takes a source file name and line number and sets a breakpoint there

The codetools package, and particularly its checkUsage function can be particularly helpful in quickly picking up syntax and stylistic errors that a compiler would typically report (unused locals, undefined global functions and variables, partial argument matching, and so forth).

setBreakpoint() is a more user-friendly front-end to trace(). Details on the internals of how this works are available in a recent R Journal article.

If you are trying to debug someone else's package, once you have located the problem you can over-write their functions with fixInNamespace and assignInNamespace, but do not use this in production code.

None of this should preclude the tried-and-true standard R debugging tools, some of which are above and others of which are not. In particular, the post-mortem debugging tools are handy when you have a time-consuming bunch of code that you'd rather not re-run.

Finally, for tricky problems which don't seem to throw an error message, you can use options(error=dump.frames) as detailed in this question: Error without an error being thrown