Try to get debugging working with LLDB

[hturner]

Expected steps:

• Build R as usual

• Use which_r to switch to the built version of R (R-devel by the standard instructions).

• Ensure CodeLLDB Extension installed

• Create a new file launch.json in the .vscode folder with the following code:

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

• Start R and run Sys.getpid() to get the process ID of the running R process.

• In the RUN AND DEBUG sidebar, select (lldb) Attach to R from the dropdown at the top, then click the green play button next to it. Paste the pid in the search bar at the top and select the corresponding process. Wait for it to get attached.

• Set a breakpoint in a C file, e.g. $TOP_SRCDIR/src/nmath/rgamma.c, by clicking to the left of a line number in the body of the function.

• Run some code that calls the C function, e.g.

rgamma(5, 1)

The debugger should start at the breakpoint set in the C code

You can also use e.g. debug(rgamma) to start the debugger from the R code that wraps the C code.

Issue with first attempt in Codespaces/Gitpod. Get error message:

Could not attach: The current value of ptrace_scope is 1, which can cause ptrace to fail to attach to a running process. 
To fix this, run:sudo sysctl -w kernel.yama.ptrace_scope=0
For more information, see: https://www.kernel.org/doc/Documentation/security/Yama.txt.

Some links that might help to work out how to fix this:

• Gitpod: GDB isn't working gitpod-io/gitpod#544
• GitHub Codespaces: https://github.com/orgs/community/discussions/51909#discussioncomment-5527904

[hturner]

I tested debugging C code in an R package with the "(lldb) Attach to R" configuration in VS Code locally. It works almost the same as in Positron, except that if you debug R code that wraps the C code at the same time, the debugging is done in R rather than the VS Code debugger.

Debugging R code:

Debugging C code:

[iaine]

It does appear that Docker still blocks ptrace by default unless a custom filter is given to Docker to allow it: https://securitylabs.datadoghq.com/articles/container-security-fundamentals-part-6/

May be we might add --cap-add=SYS_PTRACE --security-opt seccomp=unconfined to one of the container builds to see if it is enabled for debugging?
https://stackoverflow.com/questions/19215177/how-to-solve-ptrace-operation-not-permitted-when-trying-to-attach-gdb-to-a-pro

[iaine]

Having had a look at the documentation for the devcontainers JSON reference, there's an option called runArgs that may allow ptrace to be enabled. The example is rather helpful: "runArgs": [ "--cap-add=SYS_PTRACE", "--security-opt", "seccomp=unconfined" ]

Gitpod's platform is changing shortly, but not sure whether the providers will honour this call on an open platform.

[avinab-neogy]

Hi @iaine and @hturner,

Thank you very much for the helpful suggestion and links! As part of GSoC project, I wanted to ensure I fully understood the steps needed to resolve the debugging issue Heather raised, so I verified your approach regarding the Docker flags.

Adding --cap-add=SYS_PTRACE --security-opt seccomp=unconfined to runArgs indeed enables ptrace-based debugging (confirmed via strace/lldb attach in a test container). Including --privileged also easily ensured kernel.yama.ptrace_scope=0, addressing the initial error Heather encountered.

It's worth noting this verification was done using a local Docker setup; how these flags interact with the managed environments of GitHub Codespaces or Gitpod might differ.

However, as noted here, --privileged significantly reduces security by disabling most container isolation mechanisms. While effective for setup, we should be mindful of this risk.

Adding the core flags to devcontainer.json seems the right direction for local setups, with the use of --privileged needing careful consideration given the security trade-offs. Further investigation might be needed for the cloud platforms.

Thanks again!

[hturner]

I think the arguments --security-opt seccomp=unconfined should give the container the capabilities/permissions required, without giving unlimited permissions via --privileged.

Since you were able to use lldb attach that does suggest it should be sufficient. My guess is you needed to add --privileged so that you were able to use sudo within the container, to run sudo sysctl -w kernel.yama.ptrace_scope=0, but this may not be required if the container is run with --cap-add=SYS_PTRACE in the first place.

Hopefully that makes sense - I suggest we stick with adding --cap-add=SYS_PTRACE --security-opt seccomp=unconfined to runArgs for the container, rebuild, then try working through the debugging workflow as I describe in #196 (comment).

[hturner]

In fact, this comment suggests --security-opt seccomp=unconfined is not needed either.

[avinab-neogy]

Hi @hturner ,
So after a fair bit of testing I found out that we need to ad sudo sysctl -w kernel.yama.ptrace_scope=0 as well in the "postCreateCommand" in devcontainer.json
this sets the ptrace_scope to 0 while --cap-add=SYS_PTRACE --security-opt seccomp=unconfined` are the prereqs for setting ptrace_scope to 0.

was trying to figure out if we could do it without this hence it took sometime.
have a few more updates, will be posting them here before opening a PR.

[iaine]

Hi @avinab-neogy ,

This looks great. Does the postCreateCommand need sudo in it or can it just use sysctl -w kernel.yama.ptrace_scope=0 in it?

[avinab-neogy]

Hi @iaine ,

with sudo it works for sure will check without sudo as well, Thanks!

[avinab-neogy]

Heyy @iaine ,
sysctl -w kernel.yama.ptrace_scope=0 only works with sudo since it is a kernel parameter.

[hturner]

I had a look into this and think I've found a way forward.

I discovered (working locally on Ubuntu 24.04):

1. Running the Docker container with --cap-add=SYS_PTRACE is enough to be able to use lldb from a bash terminal.
   E.g. in one terminal

    cd ~/Repos/r-devel/r-dev-env
    docker build -t test-r-dev-env
    docker run --cap-add=SYS_PTRACE -it test-r-dev-env

   Build R-devel in the Docker container, run it and use Sys.getpid() to get the PID. Then in another terminal:

   docker ps
   docker exec -it <container_id> bash
   sudo lldb
   attach <pid>
   c
   break set -n "C_StemLeaf"

   Then if you return to the first terminal where R is running, stem(2) will trigger debugging in the second terminal, as expected.
2. Adding "runArgs": ["--cap-add=SYS_PTRACE"] to the devcontainer.json is enough to be able to use lldb from the bash terminal when running the devcontainer through VS Code. I.e. modify the devcontainer.json when following our local setup instructions, then use lldb as described in last point.
3. Adding "vadimcn.vscode-lldb" to the extensions in devcontainer.json in addition to the "runArgs" setting above, is not enough to launch LLDB through the CodeLLDB extension, giving the error about ptrace_scope in my first comment

So the problem is specifically about the permissions required by the CodeLLDB extension to attach the debugger to a process running in a devcontainer (even when CodeLLDB is installed in the container).

We can get round this by using prctl() to control which processes can debug the R process when we launch R.

1. Create a helper function to run prctl(), e.g. in /workspaces/r-dev-env/scripts/allow_ptrace.c

   #include <sys/prctl.h>
   __attribute__((constructor)) void allow_ptrace() {
        prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY);
   }

   Compile it with gcc -shared -fPIC -o allow_ptrace.so allow_ptrace.c.
2. Create a wrapper to launch R, e.g. in /workspaces/r-dev-env/scripts/launch_r.sh

   #!/bin/bash
   export LD_PRELOAD=/workspaces/r-dev-env/scripts/allow_ptrace.so
   exec /workspaces/r-dev-env/build/r-devel/bin/R "$@

   Make this executable with chmod +x /workspaces/r-dev-env/scripts/launch_r.sh
3. Update the r.rterm path in VS Code settings: "r.rpath.linux": "/workspaces/r-dev-env/scripts/launch_r.sh"

Then when you create an R terminal, the allow_ptrace() function is run before starting R, so that any debugger can attach to the R terminal. In particular, the Code LLDB extension will now attach, without changing the value of ptrace - using the wrapper script limits the change to the R process launched by the script, so it's much safer.

This needs a bit of finessing to integrate with our current set-up - in particular, you will need to update the which_r script, but hopefully I've given enough information here for you to reproduce this interactively and then update the dev container files so that debugging with Code LLDB will work.