Error in plyr function results in infinite loop while debugging

[dpmccabe]

I often use RStudio's debugging environment to step into various functions with a browser() call to figure out what they're doing. However, there is an extremely disruptive bug in plyr that results an infinite loop of error handling, forcing me to terminate my R session.

Here is an example script (I'm using plyr 1.8.4 and RStudio 1.0.136 on OS X):

options(error = stop)
library(plyr)

do_something <- function() {
  browser()
  
  aaply(1:10, 1, function(i) {
    return(i + 'z')
  })
}

do_something()

When I run these lines or source the file, a new tab opens inside do_something at the browser line, as expected. Then, when I try to run the aaply lines, the following two errors are printed endlessly in my console:

Error in i + "z" : non-numeric argument to binary operator
Error during wrapup: 

I cannot use either the stop sign button (in the corner of the console pane) nor the debugging environment's "Stop" button to halt the infinite loop. Rarely, mashing those buttons does stop it, but usually I need to kill the session with Session > Terminate R. Sometimes that doesn't even work, the IDE becomes unresponsive, and I have to force-quit RStudio and killall rsession to get rid of the stray process (or processes if .parallel = T is used).

Some observations:

• These are the same errors you'd get if you source the file with browser() commented out, but ostensibly there's no infinite loop and you only get the error once.
• .inform = T makes no difference.
• options(error = recover) and options(error = dump.frames) result in slightly different but still infinite and unstoppable errors. Even using a custom error handler function that does nothing but print a message does not stop the loop.
• This is not specific to RStudio. If you source the file in the R console app and paste the aaply code once you're debugging, you still get the infinite loop.
• I've seen this happen with all kinds of __ply functions and all kinds of underlying errors.
• dplyr doesn't seem to suffer from the same bug, since running x <- data_frame(a = 1:10) %>% mutate(b = a + 'z') instead of the aaply lines just gives you the error you'd expect.

Is this in fact a plyr bug or is there something wrong with base R? Is there perhaps a workaround I could use to more gracefully recover from this situation?