docker容器中的可执行文件不会通过gdb远程调试注册断点

如何解决docker容器中的可执行文件不会通过gdb远程调试注册断点

远程设置

我需要调试一个复杂的C ++程序，该程序安装在由Kubernetes控制的docker容器中。 docker容器还提供了gdbserver并公开了容器端口44444。

主机设置

用于控制和检查程序的gdb部分设置在另一个Docker容器中。这是由于以下情况：SUSE环境仅在此容器中可用，不在我的Ubuntu 18.04计算机上的VM Box中。

本地调试效果很好

在SUSE docker容器中本地调试程序效果很好。程序停止在指定的断点处，这些断点也在远程调试中指定。所有断点仅在程序的基本源代码文件中定义，而不在任何库中定义。

已验证，远程Docker容器中的可执行文件相同到主机容器中的一个；它已使用调试符号和未优化的代码（-ggdb -O0）进行了编译。

问题

仅在主机上定义的断点处停止远程调试程序。容器中的程序在后台启动。当gdbserver附加其process_id时该程序将暂停，直到在gdb主机会话中发出“继续”并转发到远程容器中的gdbserver。

该程序与基本C ++类文件，共享程序库以及共享项目库一起部署。它从参数开始，并在作业完成后退出。

程序启动时，它读取配置文件，连接到数据库，读取数据库条目，准备数据并将其格式化为XML格式的条目，然后将它们写入输出文件。

HelloWorld远程调试测试效果很好

要验证通过gdbserver端口进行的远程调试设置和连接是否工作正常，我创建了一个简单的HelloWorld C ++程序并将其复制到同一远程Docker容器中并测试其中的断点行为。

在容器中运行HelloWorld程序时，远程调试测试方案将成功运行：

内部容器端口44444映射到相同的外部端口ID 44444：
$ kubectl port-forward 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上监听
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”；一切正常

目标程序远程调试不会在断点处停止

在相同的情况下调试容器中的目标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）

要在定义的断点处停止的Docker容器中进行远程调试，我缺少什么？

解决方法

由于Ubuntu中的安全性增强（版本> = 10.10），因此不允许用户跟踪不是调试程序后代的进程。
默认情况下，进程A不能跟踪正在运行的进程B，除非B是A的直接子级（或A以root身份运行）。
仍然始终允许直接调试，例如gdb EXE和strace EXE。

可以通过将/proc/sys/kernel/yama/ptrace_scope的值从1（=默认）更改为0（=所有进程允许的跟踪）来放宽限制。可以通过以下方式更改安全设置：
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

HelloWorld远程调试测试效果很好

如何发生，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

目标程序的远程调试不会在断点处停止

一个猜测：目标程序fork()在子进程中执行并执行大多数代码（并且您的gdbserver附加了父进程）。

要验证这一点，请在目标程序的重要位置插入一些printf("%s:%d: pid=%d\n",__FILE__,__LINE__,getpid());调用。如果我的猜测是正确的，您应该看到pid在main()和connect_to_database()之间发生了变化。

docker容器中的可执行文件不会通过gdb远程调试注册断点

如何解决docker容器中的可执行文件不会通过gdb远程调试注册断点

解决方法

相关推荐