c - __libc_start_main 中的调试函数

Question

我正在编写一个库，它可以挂接一些 CUDA 函数以添加一些功能。 “构造函数” Hook CUDA 函数并设置消息队列和共享内存以与其他 Hook 的 CUDA 二进制文件通信。当启动几个 Hook 的 CUDA 二进制文件(通过 python subprocess.Popen('<path-to-binary>', shell=True) )时，一些进程挂起。所以我用了 gdb -p <pid>附上一个挂起的进程，希望能找出问题所在。结果如下:

Attaching to process 7445
Reading symbols from /bin/dash...(no debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.27.so...done.
done.
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.27.so...done.
done.
0x00007f9cefe8b76a in wait4 () at ../sysdeps/unix/syscall-template.S:78
78      ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0  0x00007f9cefe8b76a in wait4 () at ../sysdeps/unix/syscall-template.S:78
#1  0x000055fff93be8a0 in ?? ()
#2  0x000055fff93c009d in ?? ()
#3  0x000055fff93ba6d8 in ?? ()
#4  0x000055fff93b949e in ?? ()
#5  0x000055fff93b9eda in ?? ()
#6  0x000055fff93b7944 in ?? ()
#7  0x00007f9cefdc8b97 in __libc_start_main (main=0x55fff93b7850, argc=3, argv=0x7ffca7c7beb8, init=<optimized out>,
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffca7c7bea8) at ../csu/libc-start.c:310
#8  0x000055fff93b7a4a in ?? ()

我添加了 -g标志，但程序似乎卡在 wait4 上在输入之前 main .

感谢您对以下方面的任何见解:

• 如何加载这些调试符号以摆脱 ??
• ../csu/libc-start.c:310 在哪里位于？
• 我还能做些什么来定位错误？

系统信息:gcc 6.5.0 , Ubuntu 18.04与 4.15.0-54-generic .

Answer 1

How can I load these debug symbols to get rid of ??

您似乎需要 /bin/dash 的调试符号，这可能会在一个名为 dash-dbg 的包中或 dash-dbgsym或类似的东西。

此外，我怀疑如果您使用 -fno-optimize-sibling-calls 编译您的库，您的堆栈跟踪会更有意义。 .

Where is ../csu/libc-start.c:310 located?

参见 this answer .

What else can I do to locate the bug?

您说您正在编写一个使用 __attribute__((constructor)) 的库，但您显示了 /bin/dash 的堆栈跟踪(我认为是 DASH 而不是您编写的程序)似乎不涉及您库中的符号。我由此推断，您的图书馆加载了 LD_PRELOAD到不希望它在那里的程序中。

这两件事 -- LD_PRELOAD和 __attribute__((constructor)) -- 打破对所涉及的任何毫无戒心的程序和 C 库的正常期望。只有当您别无选择时，您才应该做那些事情，并且您应该尽量在注入(inject)的代码中做尽可能少的事情。 (特别是，我不认为任何涉及从构造函数生成进程的设计都是可行的，就这样。)如果您告诉我们您的更大目标，我们可能会建议更简单的替代方法。

---

编辑:

subprocess.Popen('<path-to-binary>', shell=True)

与 shell=True , Python 不直接调用程序，它运行 /bin/sh -c 'string passed to Popen' 形式的命令.在许多情况下，这自然会产生 /bin/dash。进程在 wait 中休眠(未挂起)实际二进制文件的整个生命周期的系统调用。除非您确实需要在运行程序之前评估一些 shell 代码，否则请尝试默认的 shell=False相反，看看这是否会使您的问题消失。 (如果您确实需要评估 shell 代码，请尝试 Popen('<shell code>; exec <binary>', shell=True)。)