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 Dockerfilewhich 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

Target program remote debugging doesn't stop at breakpoints

A guess: target program fork()s and executes most of the code in a child process (and your gdbserver attaches the parent).

To verify this, insert some printf("%s:%d: pid=%d\n", __FILE__, __LINE__, getpid()); calls into strategic places in the target program. If my guess is correct, you should see that the pid changes between main() and connect_to_database().