根据手册页，ltrace应该在任何执行的进程上拦截并记录动态库调用，但是在某些二进制文件上它似乎无法正常工作。
这是尝试跟踪strcpy时重现问题的方法。
我首先看到ltrace可以在某些二进制文件上工作(在此处获取wget):
# ltrace -e strcpy wget --help >/dev/null
strcpy(0x63cc23, "auth-no-challenge") = 0x63cc23
strcpy(0x63cc38, "background") = 0x63cc38
[...]
strcpy(0x63cf26, "verbose") = 0x63cf26
strcpy(0x63cf31, "verbose") = 0x63cf31
+++ exited (status 0) +++
现在，相同的代码在httpd上不起作用:
# ltrace -e strcpy /usr/sbin/httpd -t >/dev/null
Syntax OK
+++ exited (status 0) +++
尽管我们可以确认使用gdb调用了strcpy，但是没有跟踪到库调用:
# gdb --quiet --args /usr/sbin/httpd -t
Reading symbols from /usr/sbin/httpd...(no debugging symbols found)...done.
(gdb) b strcpy
Breakpoint 1 at 0x15d08
(gdb) r
Starting program: /usr/sbin/httpd -t
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaaaad1b000
[Thread debugging using libthread_db enabled]
Breakpoint 1, 0x00002aaaaca4d610 in strcpy () from /lib64/libc.so.6
我正在Fedora 17上执行此操作。这是ltrace错误还是预期行为？
最佳答案
为了获得预期的权限(setuid和 friend )和正确的守护程序配置，httpd在启动后不久即自动 fork ，然后退出原始进程(似乎在调用strcpy()之前)。 gdb自动遵循新过程，并且ltrace可以遵循新过程，但是您必须通过给它一些其他选项来告知它，例如ltrace -f。
关于linux - ltrace在某些二进制文件上不起作用，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/12899644/