我最近正在调试一个定期进行segfaulting的应用程序 - 我解决了问题，这是相对平凡的（从空指针读取），但我有一些我无法解决的剩余问题我自己的。
在大多数情况下，gdb堆栈跟踪就像这样开始：
0x00007fdff330059f in __strlen_sse42 () from /lib64/libc.so.6
使用来自/ proc / [my proc id] / maps的信息来获得共享库的基地址，我可以看到问题发生在共享库的相同指令处 - 在指令0x13259f处，这是< / p>
pcmpeqb (%rdi),%xmm1 (gdb)
到目前为止，这么好。但是，OS（linux）也会向/ var / logs / messags写出一条错误消息，看起来像这样
[3540502.783205] node[24638]: segfault at 0 ip 00007f8abbe6459f sp 00007fff7bf2f148 error 4 in libc-2.12.so[7f8abbd32000+189000]
让我感到困惑。一方面，内核正确识别故障（用户模式保护错误），并通过从指令指针中减去共享库的基地址，得到相同的相对偏移量 - 0x13259f - 就像我们一样由gdb做。但是内核识别的库是不同的，指令的地址是不同的，并且该库中的功能和指令是不同的。也就是说，libc-2-12.so中的指令是
0x13259f <__memset_sse2+911>: movdqa %xmm0,-0x43(%edx)
所以，我的问题是，gdb和内核消息如何就故障类型以及指令相对于共享库的基地址的偏移量达成一致，但是对指令指针的地址不一致正在使用的共享库？
答案 0 :(得分：1)
但是内核识别的库是不同的，
不，不是。做ls -l /lib64/libc.so.6，你会发现它是libc-2.12.so的符号链接。
指令的地址不同
内核消息用于与您在GDB中观察到的执行不同的执行，address randomization导致libc-2.12.so在不同的基地址加载。
并且该库中的功能和指令是不同的。也就是说，libc-2-12.so中的指令是
0x13259f <__memset_sse2+911>: movdqa %xmm0,-0x43(%edx)
您可能会查看与实际使用的不同的libc-2.12.so。