【问题标题】:How to find who is corrupting stack in c (linux) without using gdb?如何在不使用 gdb 的情况下找到谁在 c (linux) 中破坏堆栈?
【发布时间】:2014-10-17 18:07:11
【问题描述】:

我正在运行一个多进程应用程序,它总是在一个函数处崩溃,但我可以看到该函数的堆栈已损坏,当它从该函数内部的函数调用返回时它正在损坏。但是,当我尝试打印父函数堆栈在被调用函数内更改的位置时,它不会在被调用函数内的任何地方更改,但在从被调用函数返回后立即更改。知道为什么堆栈只有在从函数返回时才会损坏? 由于我在目标 mips 盒上运行,我试图通过 gbdserver 使用地址断点查看谁在写入该堆栈。但是 gdbserver 存在一些问题,它不跟踪我感兴趣的子进程。知道我们如何能以任何其他方式捕获谁在破坏堆栈吗?

【问题讨论】:

  • 您是否尝试在桌面 x86 Linux 系统上运行您的应用程序?
  • 它是一个mips嵌入式应用程序,需要一定的硬件支持,所以不能在普通的x86系统上运行。
  • 0) 为每个索引/指针计算添加断言 1) 分而治之:用空体替换函数体,看看错误是否消失。 2)分配相同:静默分配比您需要更多的内存;和超大的固定数组。 3) 对每个函数或函数集进行单元测试。
  • 您可能正在分发一个指向超出范围的堆栈对象的指针...仍在使用中...或使用不适当的alloca
  • 也许最近的 GCC 可能在您的 MIPS 上支持 -fsanitize=address

标签: c linux memory stack


【解决方案1】:

检查函数中分配的内存。缓冲区溢出的可能性很大。当函数返回时,它将释放所有内存,如果有任何非法内存覆盖,则可能会崩溃。

【讨论】:

    【解决方案2】:

    使用Valgrind。它向您显示对内存的无效读/写以及它们在哪里。

    【讨论】:

    • 我已经在使用 valgrind 但它显示调用返回时仅发生堆栈移位但未显示发生损坏时。我认为 valgrind 没有跟踪堆栈内存。
    • 如果您显示函数调用的代码、被调用的函数、函数原型和返回语句,那么我们就有机会调试问题。我怀疑原型、函数声明、函数调用语句和返回语句之间存在不匹配
    • 我搬到了另一个盒子,我再也看不到这个堆栈损坏了。但是使用 valgrind 至少表明存在一些问题很有用。谢谢。
    猜你喜欢
    • 1970-01-01
    • 2013-08-15
    • 2021-01-25
    • 1970-01-01
    • 2011-12-15
    • 1970-01-01
    • 1970-01-01
    • 2011-11-01
    • 1970-01-01
    相关资源
    最近更新 更多