What shoshould we do when meet a crash in Android

What shoshould we do when meet a crash in Android?

Original post address: http://leave001.blog.163.com/blog/static/1626912932011226105512484/

Create a crash

For demonstration purpose, I intentionally created a crash in open_sensors_device of libsensors:

Static int open_sensors_device (const struct hw_module_t * module, const char * Name,

Struct hw_device_t ** device)

{

Int status =-einval;

// If our sensor system is ready, commented next line

// Return status;

Char * PTR = 0;

* PTR = 0;

//....

}

PTR points to the 0 address, but it is written to the 0 address later, so it will crash. During crash, logcat can see the backtrace printed by Android:

I/systemservers (1046): Sensor Service

I/debug (971 ): **************************************** ********

I/debug (971): Build fingerprint: 'questers/Kylin/aspen168: 2.2.1/frg83/builder.20110307.131914: User/release-keys'

I/debug (971): PID: 1046, TID: 1059 >>> system_server <

I/debug (971): Signal 11 (SIGSEGV), fault ADDR 00000000

I/debug (971): R0 8150218c R1 81501250 R2 ae205500 R3 00000000

I/debug (971): R4 ae203d5b R5 8150210c R6 43891f6c R7 42084eb0

I/debug (971): R8 4a570b80 R9 42084ea8 10 42084e94 FP 0011f3e0

I/debug (971): IP a7f0110c SP 4a570b50 LR ae203247 PC 815009ba CPSR a0000030

I/debug (971): #00 PC 000009ba/system/lib/HW/sensors. Default. So

I/debug (971): #01 PC 00003244/system/lib/libandroid_servers.so

I/debug (971): #02 PC 00011cf4/system/lib/libdvm. So

I/debug (971): #03 PC 0003f194/system/lib/libdvm. So

I/debug (971): #04 PC 00016cb8/system/lib/libdvm. So

I/debug (971): #05 PC 0001d604/system/lib/libdvm. So

I/debug (971): #06 PC 0001c49c/system/lib/libdvm. So

I/debug (971): #07 PC 00055374/system/lib/libdvm. So

I/debug (971): #08 PC 0005558a/system/lib/libdvm. So

I/debug (971): #09 PC 00049672/system/lib/libdvm. So

I/debug (971): #10 pc 000113fc/system/lib/libc. So

I/debug (971): #11 PC 00010ee0/system/lib/libc. So

I/debug (971 ):

I/debug (971): code around PC:

I/debug (971): 81500998 600b189b 46c04770 00001772 fffffef4

I/debug (971): 815009a8 4d2bb5f0 rjb1c0c b083447d 90012300

I/debug (971): 815009b8 701b1869 1c161c20 efa8f7ff d11f1e07

I/debug (971): 815009c8 f7ff205c 2100ef62 1c04225c ef92f7ff

I/debug (971): 815009d8 21014821 6562424a 60676020 4a20491f

I/debug (971 ):

I/debug (971): code around LR:

I/debug (971): ae203224 b0da-80e 1820447c f7fea901 2800eaf6

I/debug (971): ae203234 9801d10f 4a0b490a 18616943 681b18a2

I/debug (971): ae203244 28004798 9801d105 1d038569 47a06fdc

I/debug (971): ae203254 2000e000 bd10b002 running 1ee8 ffffec3f

I/debug (971): ae203264 ffffec47 000003ec 4e3db5f0 4c3d1c05

I/debug (971 ):

I/debug (971): Stack:

I/debug (971): 4a570b10 4a570b80

I/debug (971): 4a570b14 42084e74

I/debug (971): 4a570b18 0027be10 [heap]

I/debug (971): 4a570b1c 0011f3e0 [heap]

I/debug (971): 4a570b20 00000001

I/debug (971): 4a570b24 00000007

I/debug (971): 4a570b28 00000000

I/debug (971): 4a570b2c 00000000

I/debug (971): 4a570b30 420ce5c0/dev/ashmem/Dalvik-linearalloc (Deleted)

I/debug (971): 4a570b34 0011f3e0 [heap]

I/debug (971): 4a570b38 0027be10 [heap]

I/debug (971): 4a570b3c 422962b0/dev/ashmem/Dalvik-linearalloc (Deleted)

I/debug (971): 4a570b40 4a570bb0

I/debug (971): 4a570b44 000000d0

I/debug (971): 4a570b48 df002777

I/debug (971): 4a570b4c e3a070ad

I/debug (971): #00 4a570b50 422962b0/dev/ashmem/Dalvik-linearalloc (Deleted)

I/debug (971): 4a570b54 8150218c/system/lib/HW/sensors. Default. So

I/debug (971): 4a570b58 45d7fd20/dev/ashmem/mspace/Dalvik-heap/2 (Deleted)

I/debug (971): 4a570b5c ae205114/system/lib/libandroid_servers.so

I/debug (971): 4a570b60 00000004

I/debug (971): 4a570b64 43891f6c/data/Dalvik-Cache/system @ framework@services.jar @ classes. Dex

I/debug (971): 4a570b68 42084eb0

I/debug (971): 4a570b6c ae203247/system/lib/libandroid_servers.so

I/debug (971): #01 4a570b70 438a922c/data/Dalvik-Cache/system @ framework@services.jar @ classes. Dex

I/debug (971): 4a570b74 8150218c/system/lib/HW/sensors. Default. So

I/debug (971): 4a570b78 4a570ba0

I/debug (971): 4a570b7c aca11cf8/system/lib/libdvm. So

D/zygote (973): Process 1046 terminated by signal (11)

Useful information

We can focus on the following five points:

1. Which process is crash?

Here there is a problem with/system/bin/system_server, and its PID is 1046.

2. CPU throw signal during crash

For example, here is 11 (segv), indicating a segment error, which is generally generated when the program command accesses an Invalid Address. For the significance of other signals, refer to advanced programming in UNIX environment. In addition, you can use kill-L to list the correspondence between the number and name:

# Kill-l

1 hup hangup 17 chld child exited

2 int interrupt 18 cont continue

3 quit 19 stop stopped (signal)

4 ill illegal instruction 20 tstp stopped

5 trap 21 ttin stopped (TTY input)

6 abrt aborted 22 ttou stopper (TTY output)

7 bus error 23 URG urgent I/O Condition

8 FPE floating point exception 24 x CPU time limit exceeded

9 kill killed 25 xfsz file size limit exceeded

10 usr1 user signal 1 26 vtalrm virtual timer expired

11 segv segmentation fault 27 Prof profiling timer expired

12 usr2 user signal 2 28 winch window size changed

13 pipe broken pipe 29 Io I/O possible

14 alrm alarm clock 30 PWR Power Failure

15 term terminated 31 sys bad system call

16 stkflt stack fault

3. Wrong address

The "fault ADDR 00000000" output from the preceding log indicates that the CPU performs read/write operations on this address except for exceptions. The null (0) address is the reserved IP address of the operating system. It is used for pointer initialization and cannot be read or written by programs.

4. PC pointer

As shown in the preceding figure

#00 PC 000009ba/system/lib/HW/sensors. Default. So

#01 PC 00003244/system/lib/libandroid_servers.so

Indicates that the CPU Instruction Pointer Points to this address when an error occurs. You can use the method described later to locate the code location by the address.

5. Stack Information

Android dumps the stack content. In Unix/Linux, the stack is generally moved to a low-address location, and Android is no exception. In the above dump information, the closer (the smaller the address) it is to the top of the stack, the closer it is to the bottom of the stack.

In addition, there are three columns in dump information:

4a570b54 8150218c/system/lib/HW/sensors. Default. So

Column 1: the address of the stack space. Here is 4a570b54

Column 2: Content in this stack unit. Here is 8150218c

Column 3: indicates the code corresponding to the content. If no text information is displayed, It is null. Here is/system/lib/HW/sensors. Default. So

Note that the address displayed here is in the complete format, that is, base address + offset. The base address can be seen from/proc/<pid>/maps (<pid> is the PID corresponding to the crash process ):

CAT/proc/1059/maps | grep "sensors. Default. So"

81500000-81502000 R-XP 00000000 00: 0f 953/system/lib/HW/sensors. Default. So

81502000-81503000 rwxp 00002000 00: 0f 953/system/lib/HW/sensors. Default. So

The preceding line (not writable) is the text segment of sensors. Default. So, And the next line is the data segment (readable and writable ). We can see that sensors. Default. So is mapped to 81500000 ~ of the system_server process ~ 81503000. After the complete code address is 8150218c minus the base address 81500000, you can get the offset of 218c in libc. So. In addition, it is noted that the 8150218c is mapped to the data segment, indicating that the stack is saved when a problem occurs.
The local variable in a function in sensors. Default. So. (Why ??)

Obtain the symbolic information from the address

Given an address, you can find its corresponding symbolic information for analysis.

Locate the Approximate Function Location

Guang @ leave001 :~ /Froyo_0308 $ vender/qsts/toolchain/arm-linux-4.1.1/bin/ARM-Linux-objdump-t out/target/product/Kylin/symbols/system/lib/sensors. default. so | sort> list.txt

Note: here you need to find the so file in out symbols, because its symbol information is not strip. List.txt contains the signed information sorted by address. According to the sensors. Default. So error address 000009ba, you can find the symbol information:

00000990 <sensors _ get_sensors_list>:

000009a8 <open_sensors_device>:

00000a8c <pick_sensor>:

We can see that the address close to 000009ba is 000009a8. Therefore, we can judge that the error function is open_sensors_device.

Locate the location

Objdump-t only prints simple information. The-S parameter can display details. The output contains C and assembly code:

Guang @ leave001 :~ /Froyo_0308 $ vendor/qsts/toolchain/arm-linux-4.1.1/bin/ARM-Linux-objdump-s out/target/product/Kylin/symbols/system/lib/sensors. default. so> list.txt

Find the function open_sensors_device in the generated list.txt. The following shows the C code and assembly:

Static int open_sensors_device (const struct hw_module_t * module, const char * Name,

Struct hw_device_t ** device)

{

9a8: b5f0 push {R4, R5, R6, R7, LR}

Int status =-einval;

// If our sensor system is ready, commented next line

// Return status;

Char * PTR = 0;

* PTR = 0;

If (! Strcmp (name, sensors_hardware_control )){

9aa: 4d2b LDR R5, [PC, #172] (A58 <. Text + 0xc8>)

9ac: 1c0c adds R4, R1, #0

9ae: ipvb LDR R1, [PC, #172] (a5c <. Text + 0xcc>)

9b0: 447d add R5, PC

9b2: b083 sub sp, #12

9b4: 2300 movs R3, #0

9b6: 9001 STR r0, [Sp, #4]

9b8: 1869 adds R1, R5, r1

9ba: 701b strb R3, [R3, #0]

9bc: 1c20 adds r0, R4, #0

9be: 1c16 adds R6, R2, #0

9c0: f7ff efa8 blx 914 <. text-0x7c>

9c4: 1e07 subs R7, R0, #0

9c6: d11f BnE. N a08 <open_sensors_device + 0x60>

The error address is 09ba. The assembly code here is

9ba: 701b strb R3, R3, #0

R3, #0 indicates that the constant 0 is transmitted to the address saved by R3, and R3 is initialized to a 0 address before. Therefore, it can be determined that the above C code is faulty.

Unfortunately, for the so generated by C ++, the output assembly and C Code are not aligned with the address, so it is not easy to find the specific location. In addition, sometimes the cause of the error is not easy to analyze from the above method. At this time, you can only use this method to narrow the scope of the code and analyze it slowly by printing and viewing the code.