GDB 在远程调试期间挂起，库版本不匹配

Posted 2023-02-25

【中文标题】GDB 在远程调试期间挂起，库版本不匹配

【英文标题】：GDB hangs during remote debugging, library version mismatches

【发布时间】：2019-11-08 18:35:49

【问题描述】：

我正在使用 linux 并尝试远程调试程序。

我在目标上启动 gdbserver，从 .xinitrc 使用

gdbserver localhost:9134 /root/game/game

在我的本地电脑上，我在 virtualbox vm 中运行，我从 gdb 连接到目标

target remote 192.168.1.20:9134

它连接良好。 我可以使用

在 main 处设置断点

b main

然后我可以继续，它会在那里中断。我可以单步执行，直到调用 SDL_Init()，它永远不会返回到 gdb。 如果我不单步执行 SDL_Init，而是在程序中进一步设置断点，程序将启动并正常运行（因此它通过 SDL_Init）。但是当它到达断点时，它会在目标机器上冻结，而我本地机器上的 gdb 永远不会显示提示。整个事情挂起，必须重新启动。但是，它并没有完全冻结，因为鼠标指针仍然在目标上移动并且您可以 ping 它，但是 gdb 连接不再起作用。因此，图形系统似乎以某种方式干扰了这一点，因为图形系统 init 之前的断点确实有效，但之后没有。

我尝试将 remotetimeout 设置为 500 秒，它表现出相同的行为。当我从本地电脑 ping 远程目标时，报告的时间大约是 0.3 到 0.4 毫秒。所以这似乎并没有什么不同，但我不排除我的任何其他错误配置的网络设置。

它在一个遗留系统上（但是嘿，它仍然赚钱），gdbserver 版本 6.8-19.fc10 和 gdb 版本 6.8-29.fc10。升级版本虽然令人头疼，但可能是可能的，但可能不是必需的（我对我的电脑所做的任何升级也必须对州监管机构的系统进行，因为他们使用 gdb 设置进行测试，但它是不是不可能）。在我接手该项目之前，远程调试过去一直在工作，之前从事过它的人都没有问过。 gdbserver 版本确实有效，因为我使用的是以前使用的确切程序。

更新 1： 我将主机上的 gdb 版本更新为 7.0.1 版本，它仍然表现出相同的行为。我不能做第 8 版，因为它需要 C++11 编译器，而旧系统在那个时间之前。

更新 2： 我已经在另一台虚拟机上试过这个，我什至构建了一个全新的专用 linux 安装（所以没有 vm），重建了软件，我得到了相同的行为。所以看来问题可能出在目标机器的配置上。

更新 3： 我挖出一条串行电缆，最后通过串行进行了远程调试设置。它仍然不起作用，但它给了我更多的错误信息。我得到了错误

gdbserver: error initializing thread_db library: version mismatch between libthread_db and libpthread

我认为这是有道理的，因为我的断点在图形系统初始化后停止工作，这涉及创建一些线程。在谷歌搜索该错误后，我尝试使用set solib-absolute-prefix、set solib-search-path 和set sysroot 到目标机器上文件系统副本的主机上的根目录（在主机上，即 /fw_dev/ fgs/cf/initrd/expand，其中包含生成 initrd 的文件系统） 但是当我尝试设置断点时，我得到Error accessing memory address 0xb5eb60: Input/output error. 我也尝试将这些变量设置到 lib 子目录，这也不起作用。我还尝试将本地线程库从主机的/lib 目录复制到目标上的/lib，但随后 x windows 甚至无法启动。

更新 #4： 我尝试从主机上目标文件系统副本的根目录 (/fw_dev/fgs/cf/initrd/expand) 启动 gdb，但 gdb 仍然挂在断点上，但我不再收到有关 libthread_db 和 libpthread 不匹配的错误消息，所以回到绘图板。

更新 #5 也许我已经到了应该问这个单独问题的地方，但是我编译了 gdb，然后自行运行 gbd。然后使用file将其设置为主机上的程序，设置远程目标，设置我的断点然后运行continue。当我到达断点时，gdb 一如既往地挂起。但是现在当我在 gdb 中按 ctrl-c 时，我得到了这个回溯

#0  0x00110416 in __kernel_vsyscall ()
#1  0x00b3f39d in ___newselect_nocancel () from /lib/libc.so.6
#2  0x08203b9a in ser_base_wait_for (scb=0x96a2930, timeout=1) at ser-base.c:206
#3  0x08203c89 in do_ser_base_readchar (scb=0x96a2930, timeout=-1) at ser-base.c:256
#4  0x08204046 in generic_readchar (scb=0x96a2930, timeout=-1, do_readchar=0x8203c60 <do_ser_base_readchar>) at ser-base.c:326
#5  0x082040b0 in ser_base_readchar (scb=0x96a2930, timeout=-1) at ser-base.c:391
#6  0x081ecac2 in serial_readchar (scb=0x96a2930, timeout=-1) at serial.c:376
#7  0x080c4357 in readchar (timeout=<value optimized out>) at remote.c:5922
#8  0x080c5e35 in getpkt_or_notif_sane_1 (buf=0x839f140, sizeof_buf=0x839f144, forever=1, expecting_notif=0) at remote.c:6440
#9  0x080d1e0a in getpkt_sane (ops=0x839f180, ptid=..., status=0xbffff388, options=0) at remote.c:6534
#10 remote_wait_as (ops=0x839f180, ptid=..., status=0xbffff388, options=0) at remote.c:4736
#11 remote_wait (ops=0x839f180, ptid=..., status=0xbffff388, options=0) at remote.c:4843
#12 0x08184d4b in target_wait (ptid=..., status=0xbffff388, options=0) at target.c:2098
#13 0x0815daf2 in wait_for_inferior (treat_exec_as_sigtrap=0) at infrun.c:2028
#14 0x0815ddd4 in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_DEFAULT, step=0) at infrun.c:1652
#15 0x08153729 in continue_1 (all_threads=0) at infcmd.c:668
#16 0x08153ea2 in continue_command (args=0x0, from_tty=0) at infcmd.c:760
#17 0x0808e9e8 in execute_command (p=0x83b89a1 "", from_tty=0) at top.c:453
#18 0x0816b028 in command_handler (command=0x83b89a0 "c") at event-top.c:511
#19 0x0816bd5a in command_line_handler (rl=0x8ce83e8 "\340&\266\b\340\230\321\b") at event-top.c:736
#20 0x0822d5a5 in rl_callback_read_char () at callback.c:205
#21 0x0816b17b in rl_callback_read_char_wrapper (client_data=0x0) at event-top.c:178
#22 0x0816ac54 in handle_file_event (data=...) at event-loop.c:812
#23 0x08169e6b in process_event () at event-loop.c:394
#24 0x0816aba4 in gdb_do_one_event (data=0x0) at event-loop.c:459
#25 0x0816500b in catch_errors (func=0x816a950 <gdb_do_one_event>, func_args=0x0, errstring=0x82ccc3d "", mask=6) at exceptions.c:510
#26 0x080f072a in tui_command_loop (data=0x0) at ./tui/tui-interp.c:153
#27 0x08165684 in current_interp_command_loop () at interps.c:291
#28 0x0808653b in captured_command_loop (data=0x0) at ./main.c:226
#29 0x0816500b in catch_errors (func=0x8086530 <captured_command_loop>, func_args=0x0, errstring=0x82ccc3d "", mask=6) at exceptions.c:510
#30 0x08085ecc in captured_main (data=0xbffff7a4) at ./main.c:902
#31 0x0816500b in catch_errors (func=0x80853d0 <captured_main>, func_args=0xbffff7a4, errstring=0x82ccc3d "", mask=6) at exceptions.c:510
#32 0x080851d1 in gdb_main (args=0xbffff7a4) at ./main.c:911
#33 0x08085195 in main (argc=128, argv=0x0) at gdb.c:33

所以 gdb 似乎挂在 __kernel_vsyscall() 中。在主机上的 /lib 目录中的 libc.so.6 上和目标上的 libc.so.6 上进行差异显示差异。我试过使用 LD_PRELOAD 和 LD_LIBRARY_PATH 但回溯总是显示 /lib/libc.so.6 而不是指向目标拥有的副本。也许我没有正确设置它们，但我尝试在 gdb 中使用set env 设置它们，并在命令行上设置它们并导出它们，但没有效果。我还尝试将主机上的 libc 放到目标机器上，它甚至无法启动，它在 libc 中出现了段错误。 那么如何让 gdb 加载不同的库呢？

更新 #6： 所以我使用目标系统的磁盘映像作为基础制作了一个可启动的 USB 密钥。我对其进行了最小的更改以使其在标准 PC 上运行，并向其中添加了 gdb 和 gdb 的必需库。所以现在，主机和目标机器上的 ibc 是相同的，它仍然挂在我身上。

决赛。虽然我知道 gdb 6.8 过去可以工作，但我无法弄清楚配置。将 两个 gdb 和 gdbserver 升级到 7.12 后，它可以工作了。

【问题讨论】：

您使用的是什么 Linux 发行版？另外，你运行的是什么内核版本？

目标上的内核 2.6.27.5-117.fc10.i686。它是从 Fedora 派生的，但它确实被剥离并使用了 BusyBox。这是一个大型嵌入式系统，虽然它使用或多或少的普通主板，但增加了硬件（GPIO、NVRAM、电池备份入侵检测等）。主机使用具有相同内核的 32 位 Fedora 10。

dmesg 怎么样？里面有什么有趣的吗？另外，系统有多少内存？

挂起后，我无法在目标上运行dmesg，因为gui已启动，我无法用键盘杀死它。我试图将 sshd 放在它上面，以为它挂起后我可以远程进入目标，但它更多的是库问题并且它存在段错误。

可以不用GUI启动，然后手动启动吗？

【参考方案1】：

升级版本虽然令人头疼，但可能但可能没有必要......

这是正确的选择。您遇到的所有其他问题都是因为这个。

我已经在另一台虚拟机中尝试过这个，我什至构建了一个全新的专用 linux 安装（所以没有 vm），重新构建了软件，我得到了相同的行为。所以看来问题可能出在目标机器的配置上。

您应该构建与您尝试将代码部署到的系统相同的版本、架构等。

但是当我尝试设置断点时，我得到 Error access memory address 0xb5eb60: Input/output error。

每this answer，

可能由 32/64 位混淆引起。例如，检查您没有附加到具有 64 位进程 ID 的 32 位二进制文​​件，反之亦然。

我也尝试将主机中的 libc 放到目标机器上，它甚至无法启动，它在 libc 中出现了段错误。

不要那样做。正如你所发现的，它不会起作用。

那么如何让 gdb 加载不同的库？

每个this question，你可以使用LD_LIBRARY_PATH。

【讨论】：

在更新 #1 中，我尽我所能将 gdb 从版本 6 升级到了 7，但仍然存在同样的问题。我不能做版本 8，因为它是一个没有 C++11 编译器的遗留系统。在项目的早期，我尝试将 gcc 升级到最新版本，但这立即在我面前爆发了。

我不认为它可以是 32/64 位混合，主机和目标都是 32 位系统。主机运行 Fedora 10，目标运行相同的内核，但使用 BusyBox 进行了精简。没有桌面或类似的东西。 Libc 在两个系统上是相同的名称和版本号，但它们并不相同，因此复制它们的尝试失败，我不确定它们为什么不同，显然编译方式不同。我尝试了 LD_LIBRARY_PATH 但我永远无法在更新 #5 的回溯中获得第 1 行来更改。因此，除非我没有完全正确，但我遵循了我在网上找到的示例。

我给你赏金。你确实说升级是答案。我确实让它与升级版的 gdb 一起工作。关键是我忘记升级 gdbserver...我知道旧版本确实可以同时工作，我们有几十个 gdb 脚本和现有的 eeprom，上面有旧的 gdbserver，所以某处存在一些配置问题。但无论如何，结果就是结果。我只需要在州监管机构构建 PC 上升级 gdb 版本...

嗯，粗鲁...它说赏金已过期...我刚刚开始工作。很抱歉。无论如何，我非常感谢您的帮助。

用于扑克/基诺机器。没有网络。因此，要进行部署，一项技术实际上会放入新媒体。软件集是 CF 卡、具有对 CF 卡的可执行部分进行散列的 optionrom 的 bios 芯片和具有要比较的散列的 eprom 芯片。主板上有另一个插槽，如果存在 eprom 并且 gdbserver 在该芯片上，则游戏软件将使用 gdbserver 启动。州监管机构使用它，因此他们可以在批准软件之前测试某些场景。好在软件有PC模式，所以我可以在本地做所有的开发。

【参考方案2】：

Here are 一些有趣的建议。您是否尝试将 gdbserver 附加到 strace 以查看挂起期间发生的活动类型？正如其他人所说 - 这可能是进一步解决问题的好方法。 您可以在目标机器上使用以下命令：

strace -p `pidof gdbserver`

同时向gdbserver 发送CONT 信号可能会在挂起时有所帮助：

kill -CONT `pidof gdbserver`

【讨论】：

kill -CONT 什么都不做。我不确定我在用strace 一堆select、recv 和send 看什么。当断点被击中并且一切都挂起时，strace 没有任何有趣的东西，只是重复显示select(7, [6], NULL, [6], 1,0) = 0 (Timeout)。