GDB 在远程调试期间挂起，库版本不匹配
GDB hangs during remote debugging, library version mismatches
我正在使用 linux 并尝试远程调试程序。
我在目标上启动 gdbserver，从 .xinitrc 使用
gdbserver localhost:9134 /root/game/game
在我的本地电脑上，我 运行 在 virtualbox 虚拟机中，我使用
从 gdb 连接到目标
target remote 192.168.1.20:9134
并且连接正常。
我可以使用
在 main 处设置一个断点
b main
然后我可以继续，它会在那里中断。我可以单步执行某种方式，直到它到达调用 SDL_Init()，它永远不会 return 返回到 gdb。
如果我不单步执行 SDL_Init 而是在程序中进一步设置断点，程序将启动并正常 运行 （因此它会通过 SDL_Init）。但是当它到达断点时，它会在目标机器上冻结，而我本地机器上的 gdb 永远不会显示提示。整个事情挂起，必须重新启动。然而，它并没有完全冻结，因为鼠标指针仍在目标上移动并且您可以 ping 它，但 gdb 连接不再有效。因此，图形系统似乎以某种方式干扰了这一点，因为图形系统初始化之前的断点起作用，但之后没有。
我试过将 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 安装（所以没有虚拟机），重建了软件，我得到了相同的行为。所以看起来问题可能出在目标机器的配置上。
更新 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：
我尝试从主机上目标文件系统副本的根目录启动 gdb (/fw_dev/fgs/cf/initrd/expand)，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 "0&6\b001\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 而不是指向目标拥有的副本。也许我没有正确设置它们，但我已经尝试使用 set env 在 gdb 中设置它们，还在命令行上设置它们并导出它们，但没有效果。我还尝试将 libc 从主机计算机放到目标计算机上，它甚至无法启动，它在 libc 中出现段错误。
那么如何让 gdb 加载不同的库呢？
更新 #6：
所以我使用目标系统的磁盘映像作为基础制作了一个可启动的 USB 密钥。我对其进行了最小的改动，使其在标准 PC 上达到 运行，并向其中添加了 gdb 和 gdb 的必需库。所以现在，ibc 在主机和目标机器上都是一样的，它仍然挂在我身上。
决赛。虽然我知道 gdb 6.8 过去工作过，但我无法弄清楚配置。将 gdb 和 gdbserver 升级到 7.12 后它工作了。
Here are 一些有趣的建议。您是否尝试将 gdbserver 附加到 strace 以查看在挂起期间发生了什么样的 activity？正如其他人所说 - 这可能是进一步解决问题的好方法。
您可以在目标机器上使用以下命令执行此操作：
strace -p `pidof gdbserver`
同时向 gdbserver 发送 CONT 信号可能会在它挂起时有所帮助：
kill -CONT `pidof gdbserver`
Upgrading versions, while a very large headache, could be possible but probably should not be necessary...
这是正确的选择。您遇到的所有其他问题都是因为这个。
I've tried this in another virtual machine and I even built a fresh dedicated linux install (so no vm), rebuilt the software, and I get the same behavior. So it appears the issue is probably on the target machine's configuration.
您应该在与您尝试将代码部署到的系统相同的版本、体系结构等上构建。
But then when I try to set breakpoints, I get Error accessing memory address 0xb5eb60: Input/output error.
每 this answer,
Can be caused by 32/64 bit mixups. Check, for example, that you didn't attach to a 32-bit binary with a 64-bit process' ID, or vice versa.
I also tried putting the libc from the host computer onto the target machine, and it won't even boot, it gets a segfault in libc.
不要那样做。如您所知，它不会起作用。
So how do I get gdb to load different libraries?
根据 this question，您可以使用 LD_LIBRARY_PATH。
我正在使用 linux 并尝试远程调试程序。
我在目标上启动 gdbserver，从 .xinitrc 使用
gdbserver localhost:9134 /root/game/game
在我的本地电脑上，我 运行 在 virtualbox 虚拟机中，我使用
从 gdb 连接到目标target remote 192.168.1.20:9134
并且连接正常。 我可以使用
在 main 处设置一个断点b main
然后我可以继续，它会在那里中断。我可以单步执行某种方式，直到它到达调用 SDL_Init()，它永远不会 return 返回到 gdb。 如果我不单步执行 SDL_Init 而是在程序中进一步设置断点，程序将启动并正常 运行 （因此它会通过 SDL_Init）。但是当它到达断点时，它会在目标机器上冻结，而我本地机器上的 gdb 永远不会显示提示。整个事情挂起，必须重新启动。然而，它并没有完全冻结，因为鼠标指针仍在目标上移动并且您可以 ping 它，但 gdb 连接不再有效。因此，图形系统似乎以某种方式干扰了这一点，因为图形系统初始化之前的断点起作用，但之后没有。
我试过将 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 安装（所以没有虚拟机），重建了软件，我得到了相同的行为。所以看起来问题可能出在目标机器的配置上。
更新 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：
我尝试从主机上目标文件系统副本的根目录启动 gdb (/fw_dev/fgs/cf/initrd/expand)，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 "0&6\b001\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 而不是指向目标拥有的副本。也许我没有正确设置它们，但我已经尝试使用 set env 在 gdb 中设置它们，还在命令行上设置它们并导出它们，但没有效果。我还尝试将 libc 从主机计算机放到目标计算机上，它甚至无法启动，它在 libc 中出现段错误。
那么如何让 gdb 加载不同的库呢？
更新 #6：
所以我使用目标系统的磁盘映像作为基础制作了一个可启动的 USB 密钥。我对其进行了最小的改动，使其在标准 PC 上达到 运行，并向其中添加了 gdb 和 gdb 的必需库。所以现在，ibc 在主机和目标机器上都是一样的，它仍然挂在我身上。
决赛。虽然我知道 gdb 6.8 过去工作过，但我无法弄清楚配置。将 gdb 和 gdbserver 升级到 7.12 后它工作了。
Here are 一些有趣的建议。您是否尝试将 gdbserver 附加到 strace 以查看在挂起期间发生了什么样的 activity？正如其他人所说 - 这可能是进一步解决问题的好方法。 您可以在目标机器上使用以下命令执行此操作：
strace -p `pidof gdbserver`
同时向 gdbserver 发送 CONT 信号可能会在它挂起时有所帮助：
kill -CONT `pidof gdbserver`
Upgrading versions, while a very large headache, could be possible but probably should not be necessary...
这是正确的选择。您遇到的所有其他问题都是因为这个。
I've tried this in another virtual machine and I even built a fresh dedicated linux install (so no vm), rebuilt the software, and I get the same behavior. So it appears the issue is probably on the target machine's configuration.
您应该在与您尝试将代码部署到的系统相同的版本、体系结构等上构建。
But then when I try to set breakpoints, I get Error accessing memory address 0xb5eb60: Input/output error.
每 this answer,
Can be caused by 32/64 bit mixups. Check, for example, that you didn't attach to a 32-bit binary with a 64-bit process' ID, or vice versa.
I also tried putting the libc from the host computer onto the target machine, and it won't even boot, it gets a segfault in libc.
不要那样做。如您所知，它不会起作用。
So how do I get gdb to load different libraries?
根据 this question，您可以使用 LD_LIBRARY_PATH。