4 Debugging R code | R debugging (2024)

4.1.1 Traceback

Let’s consider the previously showed function example with a missing variable:

# Ensure that z is missingif (exists("z")) { rm(z)}g <- function(x) { return(x + z)}f <- function(x,y = g(x)) { if (x>0) { return(x) } else { return(y) }}f(-1)## Error in g(x): object 'z' not found

This example is available here: missing-variables.R.

Opening the file with RStudio and sourcing the file will return the following kind of an error:

Now clicking the Show traceback-button will expand the traceback:

This view will quickly show that the error comes from the g(x)-function call in line #13.

Sometimes lazy evaluation can make reading the call stack complicated.Let’s have a few additional functions that are called in the argument definition:

i <- function() { return(z)}h <- function() { return(i())}f(x=-1, y=h())## Error in i(): object 'z' not found

Error is raised by i(), but looking at the call stack it almost looks like f() is somehow involved. This is because value of h() is evaluated only when it is needed in f(). Writing the code like this would reveal the true culprit:

h_value=h()## Error in i(): object 'z' not foundf(x=-1, y=h_value)## Error in f(x = -1, y = h_value): object 'h_value' not found

Of course, this is not something you want to do generally. Lazy evaluation is good for speeding up your code, so doing changes like this should be limited to situations where you’re unsure which function causes the error.

4.1.2 Traceback outside of RStudio editor

If you run the code in R console in RStudio or in a separate interpreter you might not get the Show Traceback-prompt.In those situations you can use the traceback()-function to get the trace. You can try it out with the following test in the console:

f(-1)traceback()

You can also set the R error handling to call traceback on errors:

backup_options <- options()options(error=traceback)f(-1)options(backup_options)

Here we also took a backup of the default options. This is usually a good idea as changing options will change the options for the whole R session.

4.2.1 Launching debugger with RStudio’s “Rerun with Debug”

RStudio can launch you a debugger at the location where the error occured. If you source the file again and launch the debugger with Rerun with Debug, you’ll get an interactive debugger that looks something like this:

This view has many areas of interest:

• On the top left RStudio will open the source code of the problematic functionand it tries to highlight the line that causes the error.
• On the top right we have an environment browser that shows what variables are defined insidethe g()-function’s environment.
• On the bottom right we have the traceback of the erroneous function call.The function we’re investigating is highlighted.
• On the bottom left we have the interactive debugger open in the console.

4.2.2 Debugger commands

The interactive debugger console has multiple commands (more info available here):

• Continue, c or cont: Exit the browser and continue execution at the next statement.
• Finish, f: Finish execution of the current loop or function
• Help, help: Print this list of commands
• Next, n : Evaluate the next statement, stepping over function calls. For byte compiled functions interrupted by browser calls, n is equivalent to c.
• Step, s: Evaluate the next statement, stepping into function calls. Again, byte compiled functions make s equivalent to c.
• Where, where: Print a stack trace of all active function calls.
• Resume, r: Invoke a “resume” restart if one is available; interpreted as an R expression otherwise. Typically “resume” restarts are established for continuing from user interrupts.
• Quit, Q: Exit the browser and the current evaluation and return to the top-level prompt.

RStudio also has a toolbar in debugger console with buttons for next (n), step (s), finish (f), continue (c) and stop (Q).

In addition to these commands one can run arbitrary R-commands to list variables, test their values etc.

4.2.3 debug and debugonce

You can also launch debugger from the console with debug()- and debugonce()-functions.

debug(f) will set a permanent flag that will cause a debugger to be launched wheneverfunction f is called. You can unset this variable with undebug.

Alternatively, you can use debugonce to launch the debugger once for a function. This isespecially useful if the function you want to debug is inside a for-loop. You can try this with the following:

debugonce(g)f(-1)

g_browse <- function(x) { browser() return(x + z)}f(-1, y=g_browse(x))

option(error=recover)f(-1)options(backup_options)

4.7.1 Print debugging

Print debugging is an age old debugging paradigm that usually works. Few well placedcat- or print- statements can usually tell a lot about the inner workings of theprogram.

More advanced logging packages such aslogger14,lgr15 orlog4r16 can be very useful as wellas you can leave many debug statements in your code, but print them only when needed.

One can also utilize R’ssave-functionto save environment variables for further inspection.

4.7.2 dump.frames()

dump.frames() allows you to do a recover() on a code that was run non-interactively bysaving the state of the program on error. One can then use interactive debugger() to lookinto the failed program state.

The following example from the relevant section on Advanced R illustrates the idea perfectly:

# In batch R process ----dump_and_quit <- function() { # Save debugging info to file last.dump.rda dump.frames(to.file = TRUE) # Quit R with error status q(status = 1)}options(error = dump_and_quit)# In a later interactive session ----load("last.dump.rda")debugger()