共享库中的分段错误会导致使用该库的另一个进程发生段错误吗？

Question

今天早上，我在用户主目录中遇到了一个奇怪的权限问题。 我正在运行 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进程创建核心转储。 除了su和slurmdbd是“相关”可执行文件之外，还有第二个与上述类似的“相关”分段错误实例。

我不熟悉glibc并且不构建共享库，但这让我想知道。

问题：

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

Answer 1

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

不。

可能发生的是：

• 你有故障 memory 和
• 错误的 memory 恰好是加载一些常用 GLIBC 例程的地方。 属于共享库中可执行代码的 memory 页面由使用该库的所有进程共享（这就是共享库中“共享”的含义。）。

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

PS 在这两种情况下（ 0x2b5a3708f221 - 0x2b5a3700e000和0x2afddd310221 - 0x2afddd28f000 ），崩溃都发生在 GLIBC 的偏移量0x81221 ，因此相同的指令可能已损坏。

PPS 如果您没有使用 ECC memory，则 memory 可能很好，并且损坏是由随机位翻转（例如由于宇宙辐射）引起的。