Solaris 10: советы и приёмы системного ...

Entries tagged as truss

Подписаться на этот блог

Категории

Все категории

Архивы

Visits today

Hosts: 402 (763704)
Hits: 1307 (2707554)

Tags related to tag truss

how-to howto ldd nm solaris sysadmin troubleshooting

Friday, 3 March. 2006

HOW-TO: использование ... Добавил Gleb Reys в категории SysAdmin в 11:07

Комментарии (12)
Обратные ссылки (0)

Select language: English

Defined tags for this entry: how-to, howto, ldd, nm, solaris, sysadmin, troubleshooting, truss

HOW-TO: использование команд truss, ldd и nm для наблюдения исполняемых файлов

Решил записать сюда пару полезных советов по поводу исследования исполняемых файлов в Solaris. Указанные выше команды доступны, начиная с Solaris 8, так что надеюсь, что вам эти приёмы работы пригодятся.

Очень часто случается так, что программы не работают так, как мы ожидаем, а иногда и вовсе отказываются запускаться, выдавая ошибки вроде "referenced symbol not found" (не найден символ в одной из библиотек) или что-нибудь вроде:
ld.so.1: ./thunderbird-bin: fatal: libmozjs.so: open failed: No such file or directory

Так вот, для того, чтобы точно разобраться, какими библиотеками пользуется та или иная программа, где она ожидает их найти, и что же всё-таки не находится, следует выполнить следующие шаги:

1) Сначала нужно посмотреть, какие библиотеки линковщик ld будет использовать для конкретного бинарного файла. Например, вот так можно увидеть, какие библиотеки используются исполняемым файлом почтового клиента Thunderbird:

bash-3.00$ ldd thunderbird-bin

        libmozjs.so =>   (file not found)

        libgtk-x11-2.0.so.0 =>   /usr/lib/libgtk-x11-2.0.so.0

        libgdk-x11-2.0.so.0 =>   /usr/lib/libgdk-x11-2.0.so.0

        libatk-1.0.so.0 =>       /usr/lib/libatk-1.0.so.0

        libgdk_pixbuf-2.0.so.0 =>        /usr/lib/libgdk_pixbuf-2.0.so.0

        libm.so.2 =>     /lib/libm.so.2

...

Как всегда в моих примерах, вывод команды ldd приведён не полным в целях экономии места. Но суть уже ясна. Понятно, что один из файлов - библиотека libmozjs.so - не находится. Это значит, что его нет ни в одном стандартном пути поиска библиотек линковщиком ld, и так же этого файла нету в текущем каталоге.

2) Теперь нужно определить, где линковщик ожидает найти этот самый libmozjs.so файл. Для этого мы воспользуемся командой truss. Всё, что нас интересует - это системные вызовы stat и open. stat используется для проверки нахождения файлов, а open - соответственно, открывает файлы для последующего к ним доступа.

bash-3.00$ truss -f -t stat,open ./thunderbird-bin

13070:  stat("/export/soft/thunderbird/thunderbird-bin", 0xFFBFFAD0) = 0

13070:  open("/var/ld/ld.config", O_RDONLY)             Err#2 ENOENT

13070:  stat("/export/soft/thunderbird/libc.so.1", 0xFFBFF600) Err#2 ENOENT

13070:  stat("/export/soft/thunderbird/../libc.so.1", 0xFFBFF600) Err#2 ENOENT

13070:  stat("/usr/sfw/lib/libc.so.1", 0xFFBFF600)      Err#2 ENOENT

13070:  stat("/opt/sfw/lib/libc.so.1", 0xFFBFF600)      Err#2 ENOENT

13070:  stat("/usr/local/lib/libc.so.1", 0xFFBFF600)    Err#2 ENOENT

13070:  stat("/usr/openwin/lib/libc.so.1", 0xFFBFF600)  Err#2 ENOENT

13070:  stat("/lib/libc.so.1", 0xFFBFF600)              = 0

13070:  open("/lib/libc.so.1", O_RDONLY)                = 3

13070:  stat("/export/soft/thunderbird/libxpcom.so", 0xFFBFF418) = 0

13070:  open("/export/soft/thunderbird/libxpcom.so", O_RDONLY) = 3

13070:  stat("/export/soft/thunderbird/libmozjs.so", 0xFFBFF398) Err#2 ENOENT

13070:  stat("/export/soft/thunderbird/../libmozjs.so", 0xFFBFF398) Err#2 ENOENT

13070:  stat("/usr/sfw/lib/libmozjs.so", 0xFFBFF398)    Err#2 ENOENT

13070:  stat("/opt/sfw/lib/libmozjs.so", 0xFFBFF398)    Err#2 ENOENT

13070:  stat("/usr/local/lib/libmozjs.so", 0xFFBFF398)  Err#2 ENOENT

13070:  stat("/usr/openwin/lib/libmozjs.so", 0xFFBFF398) Err#2 ENOENT

13070:  stat("/lib/libmozjs.so", 0xFFBFF398)            Err#2 ENOENT

13070:  stat("/usr/lib/libmozjs.so", 0xFFBFF398)        Err#2 ENOENT

ld.so.1: ./thunderbird-bin: fatal: libmozjs.so: open failed: No such file or directory

13070:  stat("/export/soft/thunderbird/libgtk-x11-2.0.so.0", 0xFFBFF398) Err#2 ENOENT

...

Очень хорошо видно, как линковщик последовательно перебирает стандартные пути в поисках каждой библиотеки. И для libmozjs.so мы видим, что по логике вещей этот файл должен был быть в каталоге /export/soft/thunderbird. Его там нету, потому что я для этой демонстрации его специально переименовал.
А вот так будет выглядеть ldd, когда файл оказывается на месте:

bash-3.00$ ldd thunderbird-bin

        libmozjs.so =>   /export/soft/thunderbird/libmozjs.so

        libgtk-x11-2.0.so.0 =>   /usr/lib/libgtk-x11-2.0.so.0

        libgdk-x11-2.0.so.0 =>   /usr/lib/libgdk-x11-2.0.so.0

        libatk-1.0.so.0 =>       /usr/lib/libatk-1.0.so.0

        libgdk_pixbuf-2.0.so.0 =>        /usr/lib/libgdk_pixbuf-2.0.so.0

        libm.so.2 =>     /lib/libm.so.2

...

Т.е. как раз из /export/soft/thunderbird/libmozjs.so эта библиотека и берётся.

Таким образом, комбинацией команд ldd и truss можно совершенно однозначно определить, какие библиотеки, откуда и в каком порядке читаются исполняемым файлом, за которым вы наблюдаете.

3) Для случаев с ошибками "referenced symbol not found", нужно сделать ещё один дополнительный шаг. Ошибки эти происходят чаще всего потому, что библиотека, искомая исполняемым файлом, линковщиком находится, но не содержит всех функций, которые линковщик ожидает в ней найти. Так что после пунктов 1 и 2 этого руководства, как только мы точно узнаем, какой именно файл используется для каждой подгружаемой библиотеки, мы можем воспользоваться командой nm. Во многих библиотеках хранятся тысячи доступных процедур, поэтому правильнее всего будет использовать grep с указанием частичного названия процедуры, которую ваша программа не находит в библиотеке.

Например, данная команда показывает все процедуры, доступные из библиотеки libgdk-x11-2.0, начинающиеся на gdk_threads:

bash-3.00$ nm /usr/lib/libgdk-x11-2.0.so.0 | grep gdk_threads

[3632] | 86512| 68|FUNC |GLOB |0 |11 |gdk_threads_enter

[219] | 86648| 104|FUNC |LOCL |0 |11 |gdk_threads_impl_lock

[220] | 86752| 104|FUNC |LOCL |0 |11 |gdk_threads_impl_unlock

[4329] | 86856| 212|FUNC |GLOB |0 |11 |gdk_threads_init

[3507] | 86580| 68|FUNC |GLOB |0 |11 |gdk_threads_leave

[4095] | 532720| 4|OBJT |GLOB |0 |17 |gdk_threads_lock

[3579] | 532716| 4|OBJT |GLOB |0 |17 |gdk_threads_mutex

[4391] | 87068| 144|FUNC |GLOB |0 |11 |gdk_threads_set_lock_functions

[4443] | 532724| 4|OBJT |GLOB |0 |17 |gdk_threads_unlock

Соответственно, если вы получаете ошибку "referenced symbol not found", часто это просто потому, что используется неверная версия библиотеки - более старая, или слишком новая, и нужные процедуры в ней либо отсутствуют, либо носят другие названия.

Ну, я думаю всё. Если вдруг у кого-то есть дополнения к этому небольшому руководству, то милости прошу комментировать. Буду очень рад узнать ваше мнение!

« предыдущая страница (Страница 1 из 1, всего записей: 1) следующая страница »