解释段错误消息

发布于 2024-08-27 08:11:11 字数 519 浏览 6 评论 0原文

以下段错误消息的正确解释是什么?

segfault at 10 ip 00007f9bebcca90d sp 00007fffb62705f0 error 4 in libQtWebKit.so.4.5.2[7f9beb83a000+f6f000]
segfault at 10 ip 00007fa44d78890d sp 00007fff43f6b720 error 4 in libQtWebKit.so.4.5.2[7fa44d2f8000+f6f000]
segfault at 11 ip 00007f2b0022acee sp 00007fff368ea610 error 4 in libQtWebKit.so.4.5.2[7f2aff9f7000+f6f000]
segfault at 11 ip 00007f24b21adcee sp 00007fff7379ded0 error 4 in libQtWebKit.so.4.5.2[7f24b197a000+f6f000]

What is the correct interpretation of the following segfault messages?

segfault at 10 ip 00007f9bebcca90d sp 00007fffb62705f0 error 4 in libQtWebKit.so.4.5.2[7f9beb83a000+f6f000]
segfault at 10 ip 00007fa44d78890d sp 00007fff43f6b720 error 4 in libQtWebKit.so.4.5.2[7fa44d2f8000+f6f000]
segfault at 11 ip 00007f2b0022acee sp 00007fff368ea610 error 4 in libQtWebKit.so.4.5.2[7f2aff9f7000+f6f000]
segfault at 11 ip 00007f24b21adcee sp 00007fff7379ded0 error 4 in libQtWebKit.so.4.5.2[7f24b197a000+f6f000]

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

苦笑流年记忆 2024-09-03 08:11:11

这是由于跟随空指针试图找到要运行的代码(即在取指令期间)而导致的段错误。

如果这是一个程序,而不是共享库,

请运行addr2line -e yourSegfaultingProgram 00007f9bebcca90d(并对给定的其他指令指针值重复)以查看错误发生的位置。更好的是,获得一个调试检测构建,并在 gdb 等调试器下重现问题。

不幸的是,由于它是一个共享库

,所以你已经被淹没了;事后不可能知道动态链接器将库放置在内存中的位置。在 gdb 下重现该问题。

错误的含义

如下是字段的细分:

  • address(在 at 之后) - 代码尝试访问的内存位置(很可能是 < code>10 和 11 是我们期望设置为有效值的指针的偏移量,但它指向 0

  • ip - 指令指针,即。尝试执行此操作的代码所在的位置

  • sp - 堆栈指针

  • error - 页面错误的错误代码;请参阅下文了解这在 x86 上的含义(链接)。

    <前><代码>/*
    * 页面错误错误代码位:
    *
    * 位 0 == 0:未找到页面 1:保护故障
    * 位 1 == 0:读访问 1:写访问
    * bit 2 == 0:内核模式访问 1:用户模式访问
    * 位 3 == 1:检测到保留位的使用
    * 位 4 == 1:错误是指令获取
    * 位 5 == 1:保护键阻止访问
    * 位 15 == 1:SGX MMU 页面错误
    */

This is a segfault due to following a null pointer trying to find code to run (that is, during an instruction fetch).

If this were a program, not a shared library

Run addr2line -e yourSegfaultingProgram 00007f9bebcca90d (and repeat for the other instruction pointer values given) to see where the error is happening. Better, get a debug-instrumented build, and reproduce the problem under a debugger such as gdb.

Since it's a shared library

You're hosed, unfortunately; it's not possible to know where the libraries were placed in memory by the dynamic linker after-the-fact. Reproduce the problem under gdb.

What the error means

Here's the breakdown of the fields:

  • address (after the at) - the location in memory the code is trying to access (it's likely that 10 and 11 are offsets from a pointer we expect to be set to a valid value but which is instead pointing to 0)

  • ip - instruction pointer, ie. where the code which is trying to do this lives

  • sp - stack pointer

  • error - An error code for page faults; see below for what this means on x86 (link).

    /*
     * Page fault error code bits:
     *
     *   bit 0 ==    0: no page found       1: protection fault
     *   bit 1 ==    0: read access         1: write access
     *   bit 2 ==    0: kernel-mode access  1: user-mode access
     *   bit 3 ==                           1: use of reserved bit detected
     *   bit 4 ==                           1: fault was an instruction fetch
     *   bit 5 ==                           1: protection keys block access
     *   bit 15 ==                          1: SGX MMU page-fault
     */
    
梦幻的心爱 2024-09-03 08:11:11

错误 4 表示“原因是用户模式读取导致找不到页面。”。 此处有一个工具可以对其进行解码。

这是内核的定义。请记住,4 表示设置了位 2,并且未设置其他位。如果将其转换为二进制,那就很清楚了。

/*
 * Page fault error code bits
 *      bit 0 == 0 means no page found, 1 means protection fault
 *      bit 1 == 0 means read, 1 means write
 *      bit 2 == 0 means kernel, 1 means user-mode
 *      bit 3 == 1 means use of reserved bit detected
 *      bit 4 == 1 means fault was an instruction fetch
 */
#define PF_PROT         (1<<0)
#define PF_WRITE        (1<<1)
#define PF_USER         (1<<2)
#define PF_RSVD         (1<<3)
#define PF_INSTR        (1<<4)

现在,“ip 00007f9bebcca90d”意味着发生段错误时指令指针位于0x00007f9bebcca90d。

“libQtWebKit.so.4.5.2[7f9beb83a000+f6f000]”告诉您:

  • 崩溃所在的对象:“libQtWebKit.so.4.5.2”
  • 该对象的基址“7f9beb83a000”
  • 该对象有多大:“f6f000如果

你获取基地址并从 ip 中减去它,你就得到了该对象的偏移量:

0x00007f9bebcca90d - 0x7f9beb83a000 = 0x49090D

然后你可以在它上面运行 addr2line:

addr2line -e /usr/lib64/qt45/lib/libQtWebKit.so.4.5.2 -fCi 0x49090D
??
??:0

在我的例子中它不成功,要么我安装的副本与你的不同,或者被剥离。

Error 4 means "The cause was a user-mode read resulting in no page being found.". There's a tool that decodes it here.

Here's the definition from the kernel. Keep in mind that 4 means that bit 2 is set and no other bits are set. If you convert it to binary that becomes clear.

/*
 * Page fault error code bits
 *      bit 0 == 0 means no page found, 1 means protection fault
 *      bit 1 == 0 means read, 1 means write
 *      bit 2 == 0 means kernel, 1 means user-mode
 *      bit 3 == 1 means use of reserved bit detected
 *      bit 4 == 1 means fault was an instruction fetch
 */
#define PF_PROT         (1<<0)
#define PF_WRITE        (1<<1)
#define PF_USER         (1<<2)
#define PF_RSVD         (1<<3)
#define PF_INSTR        (1<<4)

Now then, "ip 00007f9bebcca90d" means the instruction pointer was at 0x00007f9bebcca90d when the segfault happened.

"libQtWebKit.so.4.5.2[7f9beb83a000+f6f000]" tells you:

  • The object the crash was in: "libQtWebKit.so.4.5.2"
  • The base address of that object "7f9beb83a000"
  • How big that object is: "f6f000"

If you take the base address and subtract it from the ip, you get the offset into that object:

0x00007f9bebcca90d - 0x7f9beb83a000 = 0x49090D

Then you can run addr2line on it:

addr2line -e /usr/lib64/qt45/lib/libQtWebKit.so.4.5.2 -fCi 0x49090D
??
??:0

In my case it wasn't successful, either the copy I installed isn't identical to yours, or it's stripped.

给妤﹃绝世温柔 2024-09-03 08:11:11

让我们转到源代码 - 2.6.32,示例。如果设置了 show_unhandled_signals sysctl,则该消息由 arch/x86/mm/fault.c 中的 show_signal_msg() 函数打印。

“error”不是 errno 也不是信号号,它是“页面错误错误代码”——请参阅枚举 x86_pf_error_code 的定义。

“[7fa44d2f8000+f6f000]”是崩溃时映射违规对象的虚拟内存区域的起始地址和大小。 “ip”的值应适合该区域。有了这些信息,应该很容易在 gdb 中找到有问题的代码。

Let's go to the source -- 2.6.32, for example. The message is printed by show_signal_msg() function in arch/x86/mm/fault.c if the show_unhandled_signals sysctl is set.

"error" is not an errno nor a signal number, it's a "page fault error code" -- see definition of enum x86_pf_error_code.

"[7fa44d2f8000+f6f000]" is starting address and size of virtual memory area where offending object was mapped at the time of crash. Value of "ip" should fit in this region. With this info in hand, it should be easy to find offending code in gdb.

浪漫人生路 2024-09-03 08:11:11

您可以通过以下步骤修复它:

  • dmesg

Ex:
[4970814.649014] upowerd[46459]:upowerd[55ce91248000+39000] 中 8 ip 000055ce91269328 sp 00007fff71b98480 错误 4 处出现段错误
[4970840.152464] upowerd[46512]: segfault at 8 ip 000055c18f8e5328 sp 00007fffa63df280 error 4 in upowerd[55c18f8c4000+39000]

  • 找到库,这里有upowerd

  • 重新安装它,删除并安装upowerd

  • dmesg

Ex:通常,您将删除它并在最后一行提到

[4970942.517131] upowerd[47466]: segfault at 8 ip 00005637fd95b328 sp 00007ffeb77c3460 error 4 in upowerd (deleted)[5637fd93a000+3 9000]

最好的问候,

穆斯塔法·库鲁马

You can fix it with the following steps :

  • dmesg

Ex :
[4970814.649014] upowerd[46459]: segfault at 8 ip 000055ce91269328 sp 00007fff71b98480 error 4 in upowerd[55ce91248000+39000]
[4970840.152464] upowerd[46512]: segfault at 8 ip 000055c18f8e5328 sp 00007fffa63df280 error 4 in upowerd[55c18f8c4000+39000]

  • Locate the library, here you have upowerd

  • Re-install it, remove and install upowerd

  • dmesg

Ex : normally, you will have it deleted and mentioned at the last line

[4970942.517131] upowerd[47466]: segfault at 8 ip 00005637fd95b328 sp 00007ffeb77c3460 error 4 in upowerd (deleted)[5637fd93a000+39000]

Best regards,

Moustapha Kourouma

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文