【问题标题】:memcpy backtrace no symbols availablememcpy 回溯没有可用的符号
【发布时间】:2013-12-13 07:05:27
【问题描述】:

我不知道为什么我看不到这个回溯。加载了我自己的二进制文件中的符号,并安装了包libc6-dbg。我需要告诉 gdb 在哪里可以找到 libc 符号吗?

Program received signal SIGSEGV, Segmentation fault.
__memcpy_ia32 () at ../sysdeps/i386/i686/multiarch/../memcpy.S:74
74  ../sysdeps/i386/i686/multiarch/../memcpy.S: No such file or directory.
(gdb) bt full
#0  __memcpy_ia32 () at ../sysdeps/i386/i686/multiarch/../memcpy.S:74
No locals.
#1  0x00000000 in ?? ()
No symbol table info available.
(gdb)

【问题讨论】:

  • 很奇怪你没有正确的回溯,你是用“-g -O0”选项构建的吗?会不会是堆栈损坏覆盖了返回地址?
  • @jcm -O0 会影响它吗?
  • 构建器可能正在通过从二进制文件中修剪调试信息来优化您的应用程序。 -O0 禁用优化并避免这种可能性。另一方面,从回溯中的行数来看,我敢打赌堆栈损坏。我会尝试添加一个答案来帮助解决这个问题。

标签: gdb libc


【解决方案1】:

从您的回溯中,您可能有一个堆栈损坏覆盖了您的返回地址(主要是因为只有两个调用并且没有关于调用 memcpy 的代码的信息可用)。您是否有可能在堆栈中的地址上使用memcpy

检查此类损坏的一种方法是使用watch gdb 命令:

  1. 最重要的部分是界定应该被破坏的调用。在您的情况下,应该调用 memcpy 或接近它。
  2. 一旦有可疑函数,请在其上添加断点。
  3. 运行直到到达断点。
  4. 通过watch 0xXXXXXX在调用函数的地址中设置观察点
  5. 运行直到到达观察点。

如果返回地址被覆盖,db 应该在损坏调用时停止。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2014-12-17
    • 2017-12-07
    • 2015-10-10
    • 2016-02-02
    • 1970-01-01
    • 1970-01-01
    • 2011-03-18
    相关资源
    最近更新 更多