Что заставляет 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

Я получил эту ошибку с PyTorch DataLoader при использовании нескольких рабочих. Python выполняет многопроцессорную обработку, запустив множество процессов, и один из процессов имел эту ошибку при чтении файла в режиме только для чтения (для набора данных CIFAR10). Простое повторное выполнение сценария решило проблему, поэтому я считаю, что это какая-то спорадическая редкая ошибка ОС. С PyTorch, если вы установитеnum_workers=0 это также может помочь устранить ошибку.

Ниже приведена полная ошибка на случай, если кому-то интересно:

Inconsistency detected by ld.so dl-open.c   272 dl_open_worker  Assertion `_dl_debug_initialize (0, args->nsid)->r_state == RT_CONSISTENT' failed!
Traceback (most recent call last):
  File "/miniconda/envs/petridishpytorchcuda92/lib/python3.6/site-packages/torch/utils/data/dataloader.py", line 724, in _try_get_data
    data = self._data_queue.get(timeout=timeout)
  File "/miniconda/envs/petridishpytorchcuda92/lib/python3.6/queue.py", line 173, in get
    self.not_empty.wait(remaining)
  File "/miniconda/envs/petridishpytorchcuda92/lib/python3.6/threading.py", line 299, in wait
    gotit = waiter.acquire(True, timeout)
  File "/miniconda/envs/petridishpytorchcuda92/lib/python3.6/site-packages/torch/utils/data/_utils/signal_handling.py", line 66, in handler
    _error_if_any_worker_fails()
RuntimeError    DataLoader worker (pid 272) exited unexpectedly with exit code 127. Details are lost due to multiprocessing. Rerunning with num_workers=0 may give better error trace.

Answer 3

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