Gdb Does Not Hit Any Breakpoints When I Run It from Inside Docker Container

gdb does not hit any breakpoints when I run it from inside Docker container

update 2020.01.04: Use the answer given by Kevin W Matthews --- it's better because it grants the necessary individual capabilities without elevating the entire container.

tldr; use

docker run --privileged

Longer: I was having some problems with gdb in docker---it was attempting (and failing) to disable address space layout randomization---but only on docker-machine, not on my native linux host.

When gdb failed to disable ASLR, all of my breakpoints would be ignored. Using the --privileged flag fixed my issue. Your mileage may vary.

GDB is no longer hitting breakpoints in VS Code within docker container

I was looking for an answer in other resources and the most solutions say that you should -g option if you compiler a project with gcc. It wasn't my case because I use cmake but I had one detail that I debugged code that was run in docker.

When you work with files in VS code from your user and docker runs project from another user, you should add the option "sourceFileMap": {} in launch.json:

"sourceFileMap": {
                "/home/user/project/file.hpp" : "/home/YourNameBeyondDocker/project/file.hpp",
    ...

I added wrong path in this option. When I took it out, my debugger finally started hitting breakpoints!

Executable in docker container does not register breakpoints from gdb remote debugging

Due to a security enhancement in Ubuntu (versions >= 10.10), users are not allowed to ptrace processes that are not a descendant of the debugger.

By default, process A cannot trace a running process B unless B is a direct child of A
(or A runs as root).

Direct debugging is still always allowed, e.g. gdb EXE and strace EXE.

The restriction can be loosen by changing the value of /proc/sys/kernel/yama/ptrace_scope from 1 (=default) to 0 (=tracing allowed for all processes). The security setting can be changed with:

echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

HelloWorld remote debugging test works well

How did it happen, that remote debugging in the HelloWorld container worked well?

The HelloWorld container was created with USER userName in the Dockerfile
which is the same user name as been logged in to Ubuntu.

The Dockerfile for to deploy the development container (with the C++ program to be debugged) defines both a different user name and group name than being used in my Ubuntu login.

All credits for the description of ptrace scope belong to the following post,
see 2nd answer by Eliah Kagan - thank you for the thorough explanation! - here:

https://askubuntu.com/questions/143561/why-wont-strace-gdb-attach-to-a-process-even-though-im-root

GDBServer not starting or listening on port when run inside of Docker

I figured out how to run my Docker container as --privileged which allows gdbserver to run correctly. I also updated some of my CLion configs and got it working.

The useful links:

https://visualgdb.com/tutorials/linux/docker/
Run gdb inside docker container running systemd
gdb does not hit any breakpoints when I run it from inside Docker container
https://github.com/mdklatt/clion-remote

My updated docker command docker run --rm -it -v $(pwd):/source -p 7777:7777 -e container=docker --privileged schickling/rust

And my Run configuration:

GDB: Bundled
'target remote' args: tcp:localhost:7777
Symbolfile: The local copy of my compiled binary (copied from Docker thanks to volumes)
Sysroot: (blank)
Pathmappings: The absolute path to my project directory in Docker, and the absolute path to the same project directory on my local machine (the same volume)

Works like a charm.

GDB problems inside docker

This is due to apparmor. I have a solution but it needs to be applied after each boot.

The trick is to tell apparmor to 'complain' about security violations rather than block them. This isn't the most secure workaround, I'd really like to find a better way to deal with it (like only allow ptrace and whatever else GDB requires).

To tell apparmor to complain, you need to change the line in /etc/apparmor.d/docker from:

profile docker-default flags=(attach_disconnected,mediate_deleted) {

to:

profile docker-default flags=(attach_disconnected,mediate_deleted,complain) {

Running gdb in Debian docker image results

I always get the following output after starting the program with run

This error usually means that the dynamic loader in your docker container has been fully stripped. It's a packaging mistake by the creator of that container.

If you are not using dlopen(), this isn't a big problem.

(gdb) next

Don't do that: you are not stopped in a location where GDB knows where the next line is. Do continue instead.

Gdb Does Not Hit Any Breakpoints When I Run It from Inside Docker Container