ltrace не работает на некоторых двоичных файлах

Согласно man-странице, 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) +++

Вызов библиотеки не отслеживался, хотя мы можем подтвердить, что strcpy вызывается с помощью gdb:

# 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. Это ошибка трассировки или ожидаемое поведение?

1 ответ

Для достижения ожидаемых разрешений (setuid и друзья) и правильная конфигурация демона, httpd разветвляется вскоре после того, как начинается, и исходный процесс завершается (до strcpy() кажется когда-нибудь) gdb автоматически следует за новым процессом, и ltrace может следовать за ним, но вы должны сказать это, предоставив ему некоторые дополнительные опции, например ltrace -f,

Другие вопросы по тегам