Debug with RCPP

[ZIBOWANGKANGYU]

I went to posit::conf(2024) and was impressed by Positron's support for debugging from R into C. I am trying to re-produce the behavior locally but did not have success:

I have two files in the folder:

find_max.R:

library(Rcpp)
sourceCpp(file = "find_max.cpp")

max_even <- function(x){

  browser()
  if (!all.equal(x, as.integer(x))){
    stop("All numbers must be integers")
  }

  if (length(x) < 1){
    stop("Must have at least one element")
  }
  # GET LARGEST NUMBER IN C
  max <- findMax(x)
  return(max %% 2 == 0)
}

max_even(c(1, 4, 1, 352, 31, 3, 1, 61))

find_max.cpp:

#include <Rcpp.h>
using namespace Rcpp;

// [[Rcpp::export]]
int findMax(NumericVector x) {
  int n = x.size();
  int max = x[0];

  for(int i = 1; i < n; ++i) {
    if (max < x[i]){
      max = x[i];
    }
    if (i == 5){
      throw std::invalid_argument("error!");
    }
  }
  return max;
}

Then I do:

source("find_max.R")

The debugging point does not seem to go into C code as I click on "step over", as @DavisVaughan showed in his demo.

Is there anything I can do to reproduce this behavior? My team is super interested. Thanks!

[DavisVaughan]

Do you actually use sourceCpp() like this in your "real" code? Or do you use Rcpp in a package? It is much easier to do this debugging if its inside an actual package. When you use sourceCpp(), your C++ file gets copied to a cache directory (that you typically can't see) and gets built from there. So if you set any breakpoints in your find_max.cpp C++ file, they won't be activated. I was able to workaround this by forcing the cache directory to be inside my project, and then I could go set a breakpoint in the copied C++ file and that fixed things.

Also what OS are you on? We've only heavily tested this on a Mac.

Here is a longform video of me getting this to work. The files used here are here https://github.com/DavisVaughan/testrcppdebug

Screen.Recording.2024-08-30.at.11.42.07.AM.mov

It's a little more complex than what I showed in my talk - we had to greatly trim for time. But it still isn't horrible, you just need a little setup. We definitely need some real documentation for this, but here are the steps.

• First get the CodeLLDB Extension
• Then set up a .vscode/launch.json file with the contents below. If you are in a package you can also just call usethis:::use_vscode_debug() and it will set one up for you. That activates the Run and Debug launch item you can see in my video for (lldb) Attach to R.
• Get the Sys.getpid() process id for your R session, hit Attach to R, and give it the process id to attach to. This connects the C++ debugger to your R session.
• Now run sourceCpp() with the cacheDir set to something you can access. If you are using a package, this is where you'd run devtools::load_all().
• Go into the C++ file that cacheDir created, and set a breakpoint on the line of interest. Make sure the breakpoint is a filled red circle rather than an outline of a grey circle! If using a package, just go to the "real" C++ file in the package and set a breakpoint in it. This is typically much less complicated with a package because the files aren't copied around.
• Go back to the R file and step through it (this is where my video started). Once it hits the R/C++ boundary, it should activate your breakpoint.
• Now step through the C++ code

launch.json:

{
    "version": "0.2.0",
    "configurations": [
      {
        "name": "(lldb) Attach to R",
        "type": "lldb",
        "request": "attach",
        "pid": "${command:pickMyProcess}",
        "stopOnEntry": false
      }
    ]
  }

[ZIBOWANGKANGYU]

Thanks so much for this detailed reply! I appreciate it. And BTW it was nice meeting you during posit::conf(2024), if you remember I asked the question about RCPP during the morning session. I will work with my colleagues to test this out. Look forward to more documentations!

[DavisVaughan]

Our other tip is that for syntax highlighting, go to definition, and other C++ related language server features, you will also want the clangd extension (also shown in my screenshot).

clangd typically requires you to make a compile_commands.json file that teaches it information about your project, but if you work in an R package and use devtools::load_all(), then you can opt in to the fact that pkgload now knows how to generate one of these for you!

• Do pak::pak("pkgload") to get the latest version
• Then run pkgload:::use_compilation_db() and it will set things up
• The next time you call devtools::load_all() you should see a compile_commands.json file appear at the top level of your package directory
• Open up a C++ file and ideally any red squiggles will go away, and youll get completions and other fun features

This is all still experimental, hence the ::: as we get more experience with it

[ZIBOWANGKANGYU]

Hey @DavisVaughan thanks for the example and I am able to go into C code now. As I look into the "Debug Variables", it seems native C objects can show properly (see n and max) in the screenshot. However, for RCPP objects, such as x and y, only pointers are shown. Is there a way to know the actual values of the RCPP objects, for example the y below? I tried using debug console but no success. Thanks!

NumericVector y = NumericVector::create( 0.0, 1.0 );

[lionel-]

In theory you could use e.g. expr Rf_PrintValue(x) in the debug console, with x being the underlying SEXP. Or the equivalent RCPP expression. expr is a debug command that takes a C/C++ expression and evaluates it. However I think that won't work properly because the output is not sent to stdout but to another thread that relays it to the frontend via a Jupyter message, and that thread is paused in the debugger.

It might be possible to use the thread continue command (with the relevant thread as argument), and then pause again, but I have not tried this yet.

Also we might be able to provide a mutable flag actionable from the debugger to divert (or copy) output to stdout.

[DavisVaughan]

Is there a way to know the actual values of the RCPP objects

I often extract out the int / double values at each iteration into a C++ int or double variable that I can actually inspect. In general I don't have too much luck with running expr in the debug console like @lionel- suggests.

You can however directly put Rf_PrintValue(x) (i.e. print debugging) in the code once youve used the debugger to narrow down on the area of interest. Combining the two approaches is usually helpful - no silver bullet though!

[ZIBOWANGKANGYU]

Thanks @DavisVaughan and @lionel- for your reply! This is a really exciting feature for my team to try out! If possible, we would love to have more straightforward ways of debugging RCPP objects in Positron.