Как проверить, какая версия getaddrinfo находится в исполняемом файле

Question

Моя компания продает устройства на основе Linux с несколькими исполняемыми файлами.Одно из этих приложений каждые несколько дней висит в самой новой версии нашего продукта.

Мы используем glibc 2.19 и gcc 4.8.3 и ядро ​​Linux версии 3.16.38.Мы строим для x86_64.

Наша версия glibc очень старая, и мы предположительно исправили ее год назад с исправлением для: Ошибка # 12926: getaddrinfo () / make_request () вращается вечно (https://sourceware.org/bugzilla/show_bug.cgi?id=12926)

Сопровождающий нашего crosstool клянется, что у того, который мы используем, есть пропатченный glibc, но есть и другие возможности сбоев, например, наши сборки по какой-то причине могут получить другой glibc.

В нашей сборкеНа этом компьютере мы сохраняем несвязанные версии исполняемых файлов нашего приложения и двоичных файлов общих объектов, которые мы можем позже использовать при отладке файлов ядра.

Я создал несколько файлов ядра, войдя в устройство с зависшим приложением и отправивобработайте SIGILL.

Основные файлы, кажется, показывают, что мы испытываем зависание в getaddrinfo (), и трассировки стека выглядят так же, как те, которые мы использовали, чтобы получить исправление glibc. Пример из недавнего основного файла, использующегопоследняя развернутая сборка:

Thread #18 1456 (Suspended : Container)
recvmsg() at 0x7f1fa276c17d
make_request() at 0x7f1fa278695d
__check_pf() at 0x7f1fa2786e54
getaddrinfo() at 0x7f1fa2759501

Thread #16 1454 (Suspended : Container)
__lll_lock_wait_private() at 0x7f1fa277777b
_L_lock_443() at 0x7f1fa2786f4d
__check_pf() at 0x7f1fa2786d05
getaddrinfo() at 0x7f1fa2759501

Я бы хотел проверить, какая версияgetaddrinfo () исполняемые нами исполняемые файлы релиза выполняются: исправлены или не исправлены.Выполнение этого в моем личном окне разработки не поможет, потому что это только проверит мою собственную среду разработки инструментов.Могу ли я сделать это с помощью выпусков исполняемых файлов, которые мы развернули?

РЕДАКТИРОВАТЬ: я забыл упомянуть, что мы статически ссылки.

РЕДАКТИРОВАТЬ 2: Я был не прав насчет статического связывания.Мы привыкли связывать почти все статически, но мы больше не статически связываемся с системными библиотеками.Спасибо тем, кто указал на это.

Answer 1

Изменения в ошибка 12926 это просто диагностическая помощь.Если они вам нужны, в вашем приложении есть гонка файловых дескрипторов.Это может быть легче найти в результате, но это не ясно.Но ошибки приложения, связанные с условиями состязания дескриптора файла, безусловно, потребуют независимых исправлений.

В самом glibc была ошибка, которая могла вызвать неправильное повторное использование дескриптора файла, ошибка 15946 .Это исправление гораздо важнее, чем изменения в ошибке 12926. Ошибка 15946 может материализоваться разными способами, и одной из возможных причин является зависание, как в ошибке 12926.

Обратите внимание, что изменение для ошибки 15946 влияет на libresolv, который по умолчанию связан динамически, даже если приложение статически связано иным образом.Если вы не переопределите параметры сборки для glibc и ссылки libresolv также статически или не упорядочите пути поиска так, чтобы копия libresolv, которую вы отправили, были подобраны, системный glibc все равно придется исправлять.

Вы можете попытаться посмотреть на вывод /proc/PID/fd или lsof -p, как только произойдет следующее зависание.Иногда файл или сокет за файловым дескриптором дает вам подсказку, откуда он исходит, и точно определяет неправильный повторного использования файлового дескриптора в приложении.

Answer 2

Сопровождающий нашего кросс-инструмента клянется, что у того, который мы используем, есть пропатченный glibc.

Если вы не статически связываетесь (что, судя по адресу 0x7f1fa276c17d в вашем стеке)отслеживать вас не ), версия GLIBC в вашем кросс-инструменте, вероятно, не имеет значение.

Однако существуют и другие возможности сбоев, напримернаши сборки могут по какой-то причине получать другой glibc.

Обычно вы получаете GLIBC из системы , и если этот GLIBC не исправлен подобным образом, то он ожидается , что у вас все еще будет ошибка.Это , как работает динамическое связывание .

Можно использовать собственный GLIBC, установленный параллельно с системным.Однако, это не вполне тривиально .