1

我从使用 gdb 分析的核心转储中获得了以下反汇编代码。

   0x083dc366 <+194>:   call   0x83db38e <Buf::push_data(UBYTE const*, UWORD)>  
=> 0x083dc36b <+199>:   mov    eax,esi  
   0x083dc36d <+201>:   mov    edx,DWORD PTR [ebp-0x1c]

是否有可能在第一条 mov 指令处崩溃，或者 gdb 中的小箭头不可信？

4

3 回答 3

3

它可能在该特定指令上崩溃的唯一mov方法是内存不可执行（例如，跳转到恰好解码为的数据字节）。由于它似乎来自正确的代码部分，因此在这种情况下不太可能。

我怀疑 GDB 只是向您展示了函数调用返回的地方，而实际崩溃发生在被调用函数内部。也许它无法访问函数的代码或出于其他原因决定切换堆栈帧。使用检查完整的堆栈跟踪，bt并在必要时使用切换框架frame #n。

在极端情况下，转储本身可能已损坏并包含错误信息。如果您可以可靠地重现崩溃，最好从一开始就在 GDB 下运行程序，并在崩溃发生时立即捕获崩溃，以免它有机会损坏任何东西。

于 2013-03-05T17:16:53.467 回答
1

不。

两个寄存器之间的移动不应导致分段错误，因为寄存器不存储在内存中，而是在 CPU 上具有特殊位置。gdb 中的箭头不是显示当前行，而是显示指令指针的当前值，或者要运行的下一条指令，但之前的行可能尚未执行，因此它可能是崩溃的根源。

于 2013-03-05T17:12:12.310 回答
1

是否有可能在第一个 mov 指令时崩溃

不。

或者来自 gdb 的小箭头不可信

箭头应该是可信的。

您拥有“无意义”数据的最可能原因是：您重建了可执行文件，或者您向 GDB 提供了错误的可执行文件，因此崩溃的可执行文件与您指向 GDB 的可执行文件具有不同的指令。0x083dc36b

于 2013-03-05T17:17:33.330 回答