Debugging segmentation fault

Debugging segmentation fault

Type 1 Seg Fault has backtrace of shared objects (most of the times we face this)

The PC holds the offset and it has to be traced in the top most 'so' file present in back trace. This can be done by using addr2line or objdump tool

a. Using addr2line:

  Syntax: 
  <path to arm-eabi-addr2line> -f -e <path to so file> <offset which is the PC value>

  Example:
  #00  pc 0000e234  /system/lib/libc.so 
  ./prebuilt/linux-x86/toolchain/arm-eabi-4.3.1/bin/arm-eabi-addr2line -f -e ./out/target/product/generic/symbols/system/lib/libc.so 0x0000e234 

  Returns 
  strlen
  bionic/libc/arch-arm/bionic/strlen.c:62

b. Using objdump:

  Syntax: 
  <path to arm-eabi-objdump> -S <path to so file> 

  Example: 
  prebuilt/linux-x86/toolchain/arm-eabi-4.3.1/bin/arm-eabi-objdump -S out/target/product/zoom2/symbols/system/lib/libOMX.TI.Video.encoder.so > ObjDumpFile.txt
  Output is redirected to ObjDumpFile file

  Now the ObjDumpFile has the Intermix of source code with disassembly. We can search using the PC offset in it to see the exact line number

  Tip: Make sure to use the debug version of 'so' files which are within the symbols dir in out folder otherwise we would not get the source code symbols in obj dump

Type 2 Seg fault print has the thread name along with register values. The backtrace of shared objects is not present

1. The PC holds a virtual address

2. The first '3' digits of PC provide info on the virtual memory mapping where the shared object('so') is loaded and remaining digits provide the offset within the 'so'

3. Use the 'ps' call to get the Process ID of the thread where it fails.

4. Get the memory map of the process using the following:

  In device console/adb shell, print values of 'maps' file within the process id <pid>. 
  Syntax: cat proc/<pid>/maps
  It is recommended that we get the memory map during the normal execution before the failure itself otherwise it is possible for process to be killed and might lead to mismatch.

5. Use the first '3' digits of PC value to identify the shared object which has caused the failure(using memory map)

6. Get the obj dump of the 'so' and search with the offset to get the exact line of failure. (this can be done in the similar way as in Type 1 seg fault debugging mentioned above)

Example:

  Seg Fault Message:
  PV author: unhandled page fault (11) at 0x00000004, code 0x017
  pgd = ccfc8000
  [00000004] *pgd=8cbe1031, *pte=00000000, *ppte=00000000
  Pid: 9691, comm:            PV author
  CPU: 0    Not tainted  (2.6.29-omap1 #20)
  PC is at 0x81b23140
  LR is at 0x81b23049
  ...

  Based on PC, the shared object is in range of 0x81bxxxxx and offset within that is 0x23140

  PV author runs in context of Media server process (PID: 944)
  
  Using cat /proc/944/maps we can identify the ‘so’ loaded in this region
  81b00000-81b2a000 r-xp 00000000 b3:02 34574      /system/lib/libOMX.TI.Video.encoder.so
  So appears to be in OMX TI Video encoder

Now with the offset we can use the addr2line or objdump to get the line causing this issue

http://omappedia.org/wiki/Android_Debugging