【问题标题】:Linux Application glibc Stack TraceLinux 应用程序 glibc 堆栈跟踪
【发布时间】:2014-10-10 10:58:23
【问题描述】:

我的程序因堆栈跟踪而崩溃

(gdb) bt
#0  0xffffe430 in ?? ()
#1  0xf73a1765 in ?? () from /lib/libc.so.6
#2  0xf73e4da3 in ?? () from /lib/libc.so.6
#3  0xf73e989c in ?? () from /lib/libc.so.6
#4  0xf5fc6935 in MemoryFree (block=0x25757) at ../demo/demolib.c:536
.
.
.

在第 4 帧中,free() 函数被调用,我知道错误和解决方案。

问题是在上面的堆栈跟踪中,帧 0 到 3 不显示任何函数名称,只显示库 libc.so.6。在第 3 帧可能会调用 free()。

我想知道如何获取堆栈跟踪中显示的 libc.so.6 函数名称?

【问题讨论】:

  • 尝试在 valgrind 下运行它,它可能会提供有关崩溃的有用信息。
  • 问题是应用程序通常不核心。它在某些系统上进行了一次核心,我有一个核心,其堆栈跟踪在上面。所以在核心堆栈跟踪中,我想查看调用的 glibc 函数。
  • 它不必崩溃(和核心转储)。 valgrind 允许您检测某些类型的内存访问错误。如果你的程序由于内存冲突而崩溃,valgrind 会检测到它。即使程序没有崩溃,它也可以为您提供错误的线索。

标签: gdb glibc


【解决方案1】:

我想知道如何获取堆栈跟踪中显示的 libc.so.6 函数名称?

这通常会自动发生。它没有发生在你身上的原因很可能是你在~/.gdbinit 中转了auto-solib-add off

不要这样做,或者使用sharedlibrary . 在崩溃点为所有共享库加载符号。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多