Log analysis and positioning for Android Tombstone/crash

There is a word called often walk along the river, which has not wet shoes. This is what our research and development of Android's Project division is going to do, and it's something you'll often encounter when you're debugging.

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: ' xxxxxxxxx '
pid:1658, tid:13086 >>> system_server <<<
Signal (SIGSEGV), Code 1 (segv_maperr), fault addr 64696f7e
R0 00000000 R1 00000001 R2 ad12d1e8 R3 7373654d
R4 64696f72 R5 00000406 R6 00974130 R7 40d14008
R8 4b857b88 R9 4685adb4 00974130 FP 4b857ed8
IP 00000000 SP 4b857b50 lr afd11108 pc AD115EBC CPSR 20000030
D0 4040000040000000 D1 0000004200000003
D2 4e72cd924285e370 D3 00e81fe04b1b64d8
D4 3fbc71c7009b64d8 d5 3fe999999999999a
D6 4010000000000000 D7 4000000000000000
D8 4000000000000000 D9 0000000000000000
D10 0000000000000000 D11 0000000000000000
D12 0000000000000000 D13 0000000000000000
D14 0000000000000000 D15 0000000000000000
SCR 80000012

#00 PC 000108d8/system/lib/libc.so
#01 PC 0003724c/system/lib/libxvi020.so
#02 PC 0000ce02/system/lib/libxvi020.so
#03 PC 0000d672/system/lib/libxvi020.so
#04 PC 00010cce/system/lib/libxvi020.so
#05 PC 00004432/system/lib/libwimax_jni.so
#06 PC 00011e74/system/lib/libdvm.so
#07 PC 0004354a/system/lib/libdvm.so
#08 PC 00017088/system/lib/libdvm.so
#09 PC 0001c210/system/lib/libdvm.so
#10 PC 0001b0f8/system/lib/libdvm.so
#11 PC 00059c24/system/lib/libdvm.so
#12 PC 00059e3c/system/lib/libdvm.so
#13 PC 0004e19e/system/lib/libdvm.so
#14 PC 00011b94/system/lib/libc.so
#15 PC 0001173c/system/lib/libc.so

Code around PC:
ad115e9c 4620EDDC bf00bd70 0001736e 0001734e
AD115EAC 4605b570 447c4c0a f7f44620 E006edc8
Ad115ebc 42ab68e3 68a0d103 f7f42122 6864edd2
AD115ECC d1f52c00 44784803 edbef7f4 bf00bd70
Ad115edc 00017332 00017312 2100b51f 46682210

Code around LR:
Afd110e8 e2166903 1a000018 e5945000 e1a02004
Afd110f8 e2055a02 e1a00005 e3851001 ebffed92
afd11108 e3500000 13856002 1a000001 ea000009
afd11118 ebfffe50 e1a01004 e1a00006 ebffed92
afd11128 e1a01005 e1550000 e1a02006 e3a03000

Stack
4B857B10 40e43be8
4b857b14 00857280
4b857b18 00000000
4b857b1c 034e8968
4b857b20 ad118ce9/system/lib/libnativehelper.so
4b857b24 00000002
4b857b28 00000406

.....

The first day to see a direct crash, my mother, such a big lump, what things ah, totally do not understand, no clue Satan. This nnd Android out of the question, popping up such a large heap of addresses, to make wool.

In fact, I can be very responsible to tell you, brothers so much actually I can not understand, in my eyes except the red and blue places, all the rest is nonsense. With the exception of these two places, I really do not understand, a bunch of linear addresses, plus registers, like the Martian text.

Forget it, the nonsense is not much, direct analysis:

1 Red Place, is to let us confirm whether the problem occurs in that thread, is the primary thread or the child thread, the inference is based on: assuming PID and Tid Similarly, congratulations on your father's side of the problem, it seems that the problem is better. Assuming that the PID and the TID are not the same, then you are tragic and the problem is in the child thread. According to my experience, 100 of Tombstone, the problem is now the parent thread of probability, I have never found, especially what system_server, zygote these, basically are sons of the problem. Alas, who is called Father Hero, son bear ...

2 confirmed the basic point of the problem, the following is the beginning to look at the blue part.

This blue is from the #00--> #XX on the surface of the growth from the top down, in fact, the pit dad, it shows the process of running the program, precisely from the bottom up is the actual order of operation is #xx--> #00.

So at the beginning, our aim is to analyze the first failed dynamic connection library
#15 PC 0001173c/system/lib/libc.so

A first retrace, find your target, libc.so this will usually be in your compiled target folder, that is, out/target/product/your_pro/system/lib this folder.

b generally you assume that there is a decent Linux system, there will be an address resolution command addr2line, responsible for parsing the dynamic Connection library (assuming you are tragic, without this command, well, Google has long been expected to have a tragic person like you, they are in prebuilt/ Linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-addr2line, you have prepared a, how to use this bar, the same function, no difference)

ADDR2LINE-E-F libc.so 0001173c Red is your target library, green is your problem address, see #15 this line

The result appears:?? pthread_create

??: 0

Yes, well, the question should be in this function, and think it's done? I, yuck, it's early. This is just to tell you the function entry, as far as the detailed run to the function of where to hang, you have to look again.

C found out which part of the problem, the following is the opening of the microscope, to see who made the stuff.

Use objdump-s-D libc.so > Deassmble_libc.txt to disassemble your dynamic connection library file and write it to a file.

Open this disassembly after the redirection file, when the query input 1173c This offset address, you will see in the vast crowd of

00011684 <pthread_create>:
11684:E92D4FF0 Push {r4, R5, R6, R7, R8, R9, SL, FP, LR}
11688:e24dd01c Sub sp, SP, #28; 0x1c
1168C:E1A06001 mov r6, r1
11690:E1A08002 mov r8, R2
11694:E1A09003 mov R9, r3
11698:E3A04001 mov r4, #1; 0x1
1169c:e59f521c Ldr R5, [PC, #540]; 118C0 <pthread_create+0x23c>
116a0:e58d000c str r0, [sp, #12]
116a4:eb009a35 BL 37f80 <strncmp+0x20>
116a8:e59f2214 LDR R2, [pc, #532]; 118C4 <pthread_create+0x240>
116AC:E1A03000 mov R3, r0
116B0:E1A01004 mov r1, r4
116b4:e593c000 LDR IP, [R3]
116B8:E3A0003C mov r0, #60; 0x3c
116bc:e08f3005 add R3, PC, R5
116c0:e7933002 LDR R3, [R3, R2]
116c4:e5834000 str r4, [R3]
116c8:e58dc010 str IP, [sp, #16]
116cc:eb009a3b BL 37fc0 <strncmp+0x60>
...

1173c:ebffec2b bl c7f0 <__pthread_clone>--> It's him, and it's been a success for you.

...

This is arm assembly, you need to translate into the corresponding C function to see, here I do not explain, follow the previous steps,

On the above #15--> #00 a total of 16 lines to find, until found #00 line of the problem function, in fact, the last #00 line is the most important (not the front, but can give you more information, and the process), because he is the first witness, but also the first scene before crash. So it is very important to find this function, if we finally go through miles long needle found #00 error place is Pxx->member hang up (MD, I often encounter such a problem).

Then you can be suspicious of two places:

1 your pointer is a null pointer, but the reality and the ideal is always 108,000, in most cases very rarely, and after you analyze the code, you will also say how possible. In the vast majority of cases, from my experience, there are very few low-level errors such as a null pointer, but it does not rule out which of the 2 goods has this problem. Assuming this is the problem, then congratulations, you're very lucky.

2 There is suspicion of cross-border and memory addresses being squeezed out. Take my experience, the pointer is not empty, but according to the sink code, is to visit member variables hanging, this address must be occupied.

For the 2nd kind of disgusting situation, you need to look at the whole log of the process, you need to see the basic Mainlog about the appearance of crash before the action, to see which grandson occupied, to the recent principles for the first, from the bottom to see, alas, say a word, Li Bai can describe the whole process: "Shu Road difficult, It's hard to be on the sky. " Work hard and be careful. I have no idea.

Another situation, that is, memory is not enough, resulting in your address is crowding out, the presence of low memory, no more ... This statement, and the large number of things that appear gc_for_malloc about the GC (assuming a small amount, can be ignored, a lot of words), hehe shows that one of your processes is devouring your memory, there is a memory leak. This is the hardest thing to look at, you need to spend a lot of time looking at the memory changes. Generally look at the memory situation is

Cat/proc/meminfo

Spare memory =buffer+cache+free These three fields, the active field is the memory that has been used, total needless to say, is the overall physical memory. (Remember that the free is not high, does not mean that your memory spare is not high, not the amount of water, you need to see the total of 3 fields is the sum of spare memory)

Suppose you want to trace the memory usage of each process in detail, or below the/proc, the corresponding n number file, that is the PID number, the cat status can be seen after entering

Vmrss XXXKB is the amount of memory you are using in your current process, plus some other data, including pages and so on ... There is also a lot of useful data, assuming you want to track the whole process of memory, recommend that you can look at the Linux ps command source code, to see how they traverse the process under/proc, and extract the value of the property.

Write a daemon, track a period of time, record the changes in the process memory, and then the analysis of the night ....

In short, such problems, very difficult to locate, but also very difficult to solve, the need to spend time, energy to analyze. But if you do, then believe that all people will be very impressed with you. Include your boss, the quantitative change caused by qualitative change, please remember.

I'm still in a tangle ... Analysis ing

Say a few words at last

Stack

#12 476e5eb8 476e5ed8
476E5EBC 476e5ed8
476E5EC0 00100000
476E5EC4 476e5ed8
476e5ec8 acaa4d38
476E5ECC 005ec9b0
476e5ed0aca4e1a3/system/lib/libdvm.so
476e5ed4 476e5ed8
#13 476e5ed8 005ec9b0
476e5edc 005ecae8
476e5ee0 476e5f00
476e5ee4aca4e109/system/lib/libdvm.so
476e5ee8 005ec9b0
476e5eecafd11b98/system/lib/libc.so
#14 476E5EF0 476e5f00
476E5EF4 005ecae8
476e5ef8 45b29b84
476e5efcafd11740/system/lib/libc.so
#15 476e5f00 476e5f00
476e5f04 005ecae8
476e5f08 00000009
476e5f0c 00000000
476e5f10 00000000
476e5f14 005ec9b0
476e5f18 00000000
476e5f1c 00000000

The red part is base site + offset address

For example, AfD +11740 this AfD you can find every one from Prelink-linux-arm.map. So's base address (for example libc.so 0xafd00000 # [~2m]) 11740 can be from disassembly file, but I don't know what's the point.

Hope this small article can help everyone, we progress together, there are good ways to welcome you to share. Thank you!

Here is an excerpt from a foreigner's memory analysis article in the Google Forum (now NO), I was on his basis, added some analysis and experience, I hope God help me to locate the problem early.

Crashlog Analysis

Log analysis and positioning for Android Tombstone/crash