c++ - Docker容器中的可执行文件不会从gdb远程调试中注册断点

Question

远程设置
我需要调试一个复杂的C++程序，该程序安装在由Kubernetes控制的Docker容器中。
docker 容器还提供gdbserver并公开容器端口44444。
主机设置
用于控制和检查程序的gdb部分设置在另一个docker容器中。
这是由于以下情况:SUSE环境仅在此容器中可用，
不在我的Ubuntu 18.04计算机上的VM Box中。
本地调试效果很好
在SUSE docker容器中本地调试程序效果很好。程序停止
在指定的断点处，这些断点也在远程调试中指定。
所有断点仅在程序的基本源代码文件中定义，而不在任何库中定义。
已验证，远程docker容器中的可执行文件相同
到主机容器中的一个；它已使用调试符号和未优化的代码(-ggdb -O0)进行编译。
问题
远程调试程序只需要在主机上定义的断点处停止即可。
容器中的程序在后台启动。当gdbserver附加其process_id时
该程序将暂停，直到在gdb主机 session 中发出“继续”并转发到远程容器中的gdbserver为止。
该程序与基本C++类文件，共享程序库以及共享项目库一起部署。
它使用参数启动，并在作业完成后退出。
程序启动后，它会读取配置文件，连接到数据库，
读取数据库条目，准备数据并将其格式化为XML格式的条目，然后
将它们写入输出文件。
HelloWorld远程调试测试效果很好
要验证通过gdbserver端口进行的远程调试设置和连接是否工作正常，
我创建了一个简单的HelloWorld C++程序并将其复制到相同的远程Docker容器中
并测试其中的断点行为。
当在容器中运行HelloWorld程序时，远程调试测试方案将成功运行:

将内部容器端口44444映射到相同的外部端口ID 44444:
$ kubectl端口向前eric-bss-eb-tools-65c4955565-xdqtx 44444:44444
从127.0.0.1:44444转发-> 44444
从[:: 1]:44444转发-> 44444

远程容器中的

HelloWorld在后台启动并休眠几秒钟
bash-4.4 $ ./HelloWorld＆
[1] 1068

gdbserver附加到HelloWorld process_id并等待转发gdb命令
bash-4.4 $ ./gdbserver:44444 --attach 1068 // gdbserver使用暴露的端口
附； pid = 1068
在端口44444上侦听

使用TUI模式在HelloWorld源代码文件夹中启动主机容器中的

gdb
$ gdb -tui HelloWorld
从HelloWorld中读取符号...完成。
(gdb)b 13
0x400b2d处的断点1:文件HelloWorld.cpp，第13行。
(gdb)b 15
0x400b37处的断点2:文件HelloWorld.cpp，第15行。

gdb通过本地主机和(外部)端口ID 44444连接到gdbserver
(GDB)目标远程:44444
(gdb)c
继续。

，远程HelloWorld在断点2处停止；可以检查变量；
可以发出进一步的gdb命令，例如“next”和“step”；一切正常

目标程序远程调试不会在断点处停止
在相同的情况下调试容器中的 objective-c ++程序时，它不会在定义的断点处停止:

的工作流程与HelloWorld测试场景相同，不同之处在于，
在 gdb与gdbserver建立连接之后，定义断点
(目标远程:44444)。
根据此答案的第二条注释中的建议完成了此操作:(Remote gdb debugging does not stop at breakpoints)。
但是，即使在断点之后定义断点，它们仍然会被忽略
与远程目标的连接已建立。

远程docker容器中的程序被gdbserver暂停并继续
它在gdb发出“continue”命令时执行，但不会在任何断点处停止。

根据其他类似的问题描述，我尝试了一些提示，但是断点仍然被忽略。
例如。使用硬件断点，如此处相同请求的答案所建议:
(Remote gdb debugging does not stop at breakpoints)

在我的环境中，禁止使用securityContext:privileged = true运行远程docker容器，因此无法测试。在此处查看提案:
(gdb does not hit any breakpoints when I run it from inside Docker container)

在泊坞容器中定义的断点处进行远程调试时，我缺少什么？

Answer 1

由于Ubuntu中的安全性增强(版本> = 10.10)，因此不允许用户跟踪不是调试器后代的进程。
默认情况下，进程A不能跟踪正在运行的进程B，除非B是A的直接子级
(或A作为根运行)。
仍然始终允许直接调试，例如gdb EXE和strace EXE。
可以通过将/proc/sys/kernel/yama/ptrace_scope的值从1(=默认)更改为0(=所有进程允许的跟踪)来放宽此限制。可以通过以下方式更改安全设置:echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

HelloWorld remote debugging test works well

发生在HelloWorld容器中的远程调试很好吗？
HelloWorld容器是使用Dockerfile中的 USER userName创建的
与登录Ubuntu的用户名相同。
用于部署开发容器(带有要调试的C++程序)的Dockerfile定义了与我的Ubuntu登录名所使用的用户名和组名不同的用户名和组名。
描述ptrace作用域的所有功劳都属于以下帖子，
请参阅Eliah Kagan的第二个答案-感谢您的详尽解释! - 这里:
https://askubuntu.com/questions/143561/why-wont-strace-gdb-attach-to-a-process-even-though-im-root