Question

我在共享库中有一个sigfault。有一个堆栈跟踪。

(_bad_func+0x3dd)

功能定义是：

000000000008b030 <_bad_func>:

我发现问题所在（0x08b950 + 0x3dd =＆gt; 0x8bd2d）并感到困惑。

   8bd23:   bf 03 00 00 00          mov    $0x3,%edi
   8bd28:   e8 03 ca fe ff          callq  78730 <sleep@plt>
   8bd2d:   c6 04 25 00 00 00 00    movb   $0x0,0x0
   8bd34:   00 
   8bd35:   e9 3a ff ff ff          jmpq   8bc74 <xxx+0x324>

我认为＆＃34; movb $ 0x0,0x0＆＃34;总是失败。它将0字面写入nullptr。为什么编译器把它放在这里？睡眠功能是很常见的系统之一。我猜它没有触及它的返回地址。因此在睡眠3秒后100％该过程收到段错误。

如果存在用于对齐下一条指令的存根字节，为什么不是它们只是零（或1字节指令NOP = 90）。

这是Intel elf64代码。

_bad_func在gdb中看起来是一样的。

gdb proc
br xxx   # stop and at the func after library initialized
start
disas _bad_func

   0x00002aaaaaf5dd23 <+979>:   mov    $0x3,%edi
   0x00002aaaaaf5dd28 <+984>:   callq  0x2aaaaaf4a730 <sleep@plt>
   0x00002aaaaaf5dd2d <+989>:   movb   $0x0,0x0
   0x00002aaaaaf5dd35 <+997>:   jmpq   0x2aaaaaf5dc74 <xxx+804>

Answer 1

可能是图书馆发出致命错误的信号 - 故意崩溃。或者，零可能是可重定位地址的占位符，应该由加载器修补。尝试使用重定位信息进行反汇编：

objdump -dr libmylib.so

我建议使用调试器，例如gdb，而不是通过反汇编来追踪问题。它将在运行时向您显示故障的确切位置以及实际指令（而非占位符）。

顺便说一句，你的数学是错误的。 0x8B030 + 0x3DD为0x8B40D。

方法调用后写入零的含义是什么？

1 个答案: