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