Что заставляет sprof жаловаться на «несоответствие, обнаруженное ld.so»?

Question

Я пытаюсь использовать sprof для профилирования некоторого программного обеспечения (ossim), где почти весь код находится в общей библиотеке. Я сгенерировал файл профилирования, но когда я запускаю sprof, я получаю следующую ошибку:

> sprof /home/eca7215/usr/lib/libossim.so.1 libossim.so.1.profile -p > log
Inconsistency detected by ld.so: dl-open.c: 612: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed!

В инструкциях, которым я следовал, сказано, что мне нужна версия libc как минимум 2.5-34, у меня версия libc 2.12.2 (Gentoo, ядро ​​2.6.36-r5).

Я не могу найти никакого объяснения относительно того, что означает ошибка или (что более интересно), как ее исправить, единственные наполовину релевантные результаты Google относятся к ошибке в старой версии Skype.

Answer 1

Мне стало немного любопытно, поскольку это все еще не работает в OpenSuse 12.x. Я бы подумал, что ошибка, о которой первоначально сообщалось в '09 или около того, уже исправлена. Я думаю, что никто не использует спроф. (или, может быть, dl-open настолько хрупок, что люди боятся его трогать: -)

Проблема сводится к флагу __RTLD_SPROF, используемому в качестве аргумента для dlopen. Возьмите любую простую программу, которая вызывает dlopen или этот флаг, ко второму аргументу, и вы получите то же самое ошибочное утверждение. Я использовал образец программы в нижней части http://linux.die.net/man/3/dlopen в качестве примера

handle = dlopen(argv[1], RTLD_LAZY | __RTLD_SPROF);

Из того, что я могу судить по беглому взгляду на dl-open.c, это помечает короткие замыкания того, что делает dl_open. Таким образом, r_flag, указанный в утверждении, не устанавливается равным RT_CONSISTENT.

Answer 2

Если вы используете Docker, может быть другое объяснение. В моем случае данные профилирования были сгенерированы из процесса, выполняющегося внутри контейнера Docker, я попытался запустить sprof изнутри контейнера и получил ту же ошибку, как описано в вопросе. Запуск sprof от хоста (вместо контейнера) решил эту проблему.