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

问题描述

今天早上，我的用户主目录遇到一个奇怪的权限问题。我正在运行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，并且不构建共享库，但这让我感到奇怪。

问题：

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

解决方法

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

否。

可能发生的情况是：

• 您的记忆力有误，
• 错误的内存恰巧是某些常用的GLIBC例程加载到的地方。共享库中属于可执行代码的内存页由使用该库的所有进程共享（这就是共享库中“共享”的意思！）。

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

P.S。在两种情况下（0x81221和0x2b5a3708f221 - 0x2b5a3700e000，崩溃都发生在偏移量0x2afddd310221 - 0x2afddd28f000进入GLIBC的情况下，因此同一条指令很可能已损坏。

P.P.S。如果您不使用ECC内存，则内存可能很好，并且损坏是由随机的位翻转（例如由于宇宙辐射引起的）引起的。