20

我正在尝试使用 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）。

我找不到关于错误意味着什么或（更有趣的是）如何修复它的任何解释，唯一半相关的谷歌结果是旧版本 Skype 中的错误。

4

3 回答 3

7

我有点好奇，因为这在 OpenSuse 12.x 中仍然存在问题。我会认为最初在 09 年左右报告的错误现在已经修复了。我想没有人真正使用sprof。（或者也许 dl-open 太脆弱以至于人们害怕触摸它:-)

问题归结为用作 dlopen 参数的 __RTLD_SPROF 标志。将任何调用 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。

于 2012-06-06T20:36:17.543 回答
3

使用多个工作人员时，我使用 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.
于 2019-12-11T12:27:32.003 回答
1

如果您使用的是 Docker，可能会有另一种解释。在我的情况下，分析数据是从在 Docker 容器内运行的进程生成的，我尝试从容器内运行 sprof 并收到与问题中描述的相同的错误。从主机（而不是容器）运行 sprof 解决了它。

于 2019-06-25T15:42:17.720 回答