0

I've got a sigfault inside a shared library. There is a stack trace.

(_bad_func+0x3dd)

Function definition is:

000000000008b030 <_bad_func>:

I found the problem place (0x08b950 + 0x3dd => 0x8bd2d) and get puzzled. 

   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>

I think "movb $0x0,0x0" is always fails. It writes 0 literal to nullptr. Why did the compiler put it here? Sleep function is pretty usual system one. I guess it doesn't touch its return address. So 100% after it sleeps for 3 seconds the process receives segfault.

If there are stubbing bytes used to align next instruction why not are they just zeros (or 1 byte instruction NOP = 90).

This is Intel elf64 code.

The _bad_func looks the same from 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>
Daniil Iaitskov
  • 5,525
  • 8
  • 39
  • 49
  • *Why did the compiler put it here?* - maybe the shared library has a buggy statement/sequence-of-statements that translates to this? – ArjunShankar May 21 '14 at 10:40
  • That's a non-resolved external variable. Is that fromn `objdump -d`? Try with `objdump -r -R -d` – ninjalj May 21 '14 at 10:58

1 Answers1

2

Possibly it is how the library signals fatal errors - by crashing intentionally. Or, possibly, the zeroes are a placeholder for a relocatable address and are supposed to be patched by the loader. Try disassembling with relocation info:

objdump -dr libmylib.so

Instead of trying to track down the issue by disassembling, I would recommend using a debugger, such as gdb. It will show you the exact place of the fault, and the actual instructions (not placeholders) at runtime.

By the way, your math is wrong. 0x8B030 + 0x3DD is 0x8B40D.

Igor Skochinsky
  • 24,629
  • 2
  • 72
  • 109