【问题标题】:Can a segmentation fault in a shared library cause another process using that library to segfault?共享库中的分段错误会导致使用该库的另一个进程发生段错误吗?
【发布时间】:2020-12-01 07:31:30
【问题描述】:

今天早上,我在用户主目录中遇到了一个奇怪的权限问题。我正在运行 CentOS 6.9。这导致像 ls -su user 这样的事情失败。在同一秒内,在其中一个分段错误期间,另一个进程 (slurmctld) 在同一个库中发生了分段错误。这是来自/var/log/messages 的相关摘要。

Aug 11 09:47:10 qmaster01 kernel: slurmctld[31279]: segfault at 0 ip 00002b5a3708f221 sp
00007ffd8414ada8 error 4 in libc-2.12.so[2b5a3700e000+18b000]
.
.
.
Aug 11 09:47:37 qmaster01 kernel: su[1199]: segfault at 0 ip 00002afddd310221 sp 00007ffc3fecd308 error 4 in libc-2.12.so[2afddd28f000+18b000]

现在我无法对这个问题进行全面分析,因为系统未能为slurmctld 进程创建核心转储。除了suslurmdbd 是“相关”可执行文件之外,还有第二个“相关”分段错误实例。

我不熟悉 glibc 并且不构建共享库,但这让我感到疑惑。

问题

使用生成分段错误的共享库的进程是否可能在使用同一库的其他进程中导致分段错误?如果是,在什么条件下或提供一个例子。

【问题讨论】:

    标签: segmentation-fault shared-libraries glibc


    【解决方案1】:

    使用共享库生成分段错误的进程是否有可能在使用同一库的其他进程中导致分段错误?

    没有。

    可能发生的事情是:

    • 你的内存有问题并且
    • 错误的内存恰好是加载一些常用 GLIBC 例程的位置。共享库中属于可执行代码的内存页面由使用该库的所有进程共享(这就是共享库中“共享”的含义!)。

    您可能应该在机器上运行 memtest86 几个小时。

    附:在这两种情况下(0x2b5a3708f221 - 0x2b5a3700e0000x2afddd310221 - 0x2afddd28f000),崩溃都发生在偏移量 0x81221 到 GLIBC 中,因此同一条指令可能已损坏。

    附言如果您没有使用 ECC 内存,则可能是内存没有问题,而损坏是由随机位翻转引起的(例如,由于宇宙辐射)。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2010-11-13
      • 2023-03-12
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-10-19
      • 1970-01-01
      相关资源
      最近更新 更多