Crash/tombstone Analysis Method

There is a saying that the shoes are always walking by the river. Our research and developmentAndroidThe engineer is responding to this sentence. It is imperative that you will often encounter such a thing during debugging.

**************************************** ********
Build fingerprint: 'xxxxxxxxxxx'
PID: 1658, TID: 13086 >>> system_server <
Signal 11 (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 10 00974130 FP 4b857ed8
IP 00000000 SP 4b857b50 LR afd11108 PC ad115ebc CPSR 20000030
D0 4040000040000000 D1 0000004200000003
D2 4e72cd924285e370 D3 00e81fe04b1b64d8
D4 3fbc71c7009b64d8 D5 3fe99999999999999a
D6 4010000000000000 D7 4000000000000000
D8 4000000000000000 D9 0000000000000000
D10 0000000000000000 D11 0000000000000000
D12 0000000000000000 D13 0000000000000000
D14 0000000000000000 D15 0000000000000000
SCR 80000012

#00 PC 0001_d8/system/lib/libc. So
#01 PC 0003724c/system/lib/libxvi0#so
#02 PC performance02/system/lib/libxvi0#so
#03 PC iisd672/system/lib/libxvi0#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 4620 eddc 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 1a42418 e5945000 e1a02004
Afd110f8 e2055a02 e1a00005 e00001001 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
00000002 b857b24
4b857b28 00000406

.....

I saw a crash on the first day. My mom, it's such a big mess. I don't know what it is, and I don't have a clue. This nnd android has a problem. A bunch of addresses are coming up.

In fact, I can tell you responsibly that I can't understand so many of my brothers. In my eyes, everything except red and blue is nonsense. Except for these two places, I really don't understand anything else. A bunch of linear addresses, plus registers, are the same as those in Mars.

If you don't have much nonsense, analyze it directly:

1. The red color indicates whether the problem occurs in the thread, whether it is the main thread or the sub-thread. The judgment is based on: If the PID is the same as the TID, congratulations! The problem lies with your father. It seems that it is easy to ask questions. If the PID and TID are different, then you are miserable. The problem lies in the Child thread. According to my experience, in Tombstone 100, the probability of a problem occurring in the parent thread has never been found, especially system_server and zygote, which are basically son problems. Alas, who is the hero of Father? What about a bear...

2. Confirm the basic points of the problem. Here is the blue part.

This blue color is not counted from #00 --> # XX on the surface, it seems to have grown from top to bottom. In fact, it shows the execution process of the program, it is precisely from the bottom up, that is, the actual execution order is # xx --> #00.

So our goal at the beginning was to analyze the first problematic dynamic Connection Library.
#15 PC 0001173c/system/lib/libc. So

A first, follow the steps shown in the figure to find your target. libc. So is usually stored in the compiled target directory, that isOut/target/product/your_pro/system/libUnder this directory.

B. Generally, if you are using a decent Linux system, you will have an address resolution command addr2line to parse the dynamic Connection Library (if you are a tragedy and do not have this command, okay, google has long been expected to have a tragedy like you, they in prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-addr2line, for you to prepare a, how to use this, the function is the same, no difference)

Addr2line-e-f libc. So
0001173c Red is your target database, and green is the address of your problem. Please refer to #15.

The result is :?? Pthread_create

?? : 0

Well, the problem should be in this function and I think it's done? I, sorry, it's still early. This is just to tell you the function entry, as to the specific place where the function is executed, you have to look at it again.

C finds out which part has gone wrong. The following is how to turn on the microscope to see who is doing something.

Use objdump-s-d libc. So> deassmble_libc.txt to decompile your dynamic connection library file and write it into a file.

Open the redirection file after the disassembly, and enter1173cThis offset address, you will see in the vast sea of people

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>
Running A0: e58d000c STR r0, [Sp, #12]
A4: eb009a35 BL 37f80 <strncmp + 0x20>
2017a8: e59f2214 LDR R2, [PC, #532]; 118c4 <pthread_create + 0x240>
116ac: e1a03000 mov R3, R0
Required B0: e1a01004 mov R1, r4
Listen B4: e593c000 ldr ip, [R3]
Listen B8: e3a0003c mov r0, #60; 0x3c
Hybrid BC: e08f3005 add R3, PC, R5
2017c0: e7933002 LDR R3, [R3, R2]
C4: e5834000 STR R4, [R3]
C8: e58dc010 str ip, [Sp, #16]
116cc: eb009a3b BL 37fc0 <strncmp + 0x60>
...

1173c: ebffec2b BL c7f0 <__ pthread_clone> --> it's him.

...

This is an arm assembly. You need to translate it into the corresponding C function. I will not explain it here. Follow the steps above,

Find 16 rows in the previous section #15 --> #00 until the problematic function of line #00 is found. In fact, the last line #00 is the most important (you can leave it blank, but you can give you more information, and procedures), because he is the first witness and the first scene before the crash. So it is very important to find this function. Let's assume that pxx-> member has crashed (MD, I often encounter this problem ).

You may doubt the following two points:

1. Your Pointer is a null pointer, but the reality and ideal are always within 108,000. In most cases, it rarely appears. After analyzing the code, you can also say to yourself how possible. In most cases, from my experience, there are very few low-level errors such as null pointers, but I don't know which two products have such a problem. If this is the case, congratulations, you are lucky.

2. It is suspected that the out-of-bounds and memory address are occupied. In my previous experience, the pointer is not empty, but according to the assembly code, the access member variable is suspended, and this address must be occupied.

For 2nd cases, you need to check the entire log process. You need to check the main mainlog action before the crash occurrence to see which grandson is occupying it, starting from the bottom up, Li Bai's sentence can describe the entire process: "It's hard to get down to Heaven ". The workload is heavy and meticulous. I can't do anything, either...

Another case is that the memory is insufficient, which causes your address to be occupied. low memory, no more... such a statement and a large number of gc_for_malloc GC-related things (if a small number of, can be ignored, a large number of) indicate that a process is consuming your memory, memory leakage exists. This is the most difficult issue to query. you need to spend a lot of time looking at memory changes. Generally, the memory is

CAT/proc/meminfo

Idle memory = buffer + cache + free. The active field is the memory used, not to mention the total physical memory. (Remember that free is not high, it does not mean that your memory is not idle. You can't afford it. You need to check that the total of the three fields is the idle memory)

If you want to track the memory usage of each process, or under/proc, it corresponds to more than N numeric files, which is actually a PID Number. After entering, you can see the cat status

Vmrss xxxkb is the amount of memory used by your current process. In addition, there are some other memory data, including pages... There is a lot of useful data in it. If you want to track the memory of all the processes, you can look at it.Linux psCommand source code to see how people traverse the process under/proc and extract the attribute value.

Write a daemon, track the changes in the memory of each process for a period of time, and then analyze it overnight ....

 

In short, such problems are difficult to locate and solve. It takes time and effort to analyze them. But if you solve it, then I believe everyone will be impressed with you. Including your boss, quantitative changes cause qualitative changes, please remember.

 

I am still struggling... analyzing ing

 

Last few words

STACK:

#12 476e5eb8 476e5ed8
476e5ebc 476e5ed8
476e5ec0 00100000
476e5ec4 476e5ed8
476e5ec8 acaa4d38
476e5ecc 005ec9b0
476e5ed0 aca4e1a3/system/lib/libdvm. So
476e5ed4 476e5ed8
#13 476e5ed8 005ec9b0
476e5edc 005ecae8
476e5ee0 476e5f00
476e5ee4 aca4e109/system/lib/libdvm. So
476e5ee8 005ec9b0
476e5eec afd11b98/system/lib/libc. So
#14 476e5ef0 476e5f00
476e5ef4 005ecae8
476e5ef8 45b29b84
476e5efc afd11740/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 the base address + offset address.

For example AFD + 11740 this AFD you can find the base address of each. So from the prelink-linux-arm.map (such
Libc. So 0xafd00000 #[~ 2 m]) 11740 you can find the corresponding point from the disassembly file, but I don't know what these are useful.

I hope this small article will help you and make progress together. You are welcome to share it with us if you have any good methods. Thank you!

The following is an excerpt from a foreigner stored in GoogleForumThe memory analysis article (now no), I added some analysis and experience based on him, hope God bless me to locate the problem early.

Crashlog Analysis

Original article address:

Http://www.6619.net/a/kaifalingyu/yidongyingyong/Android/jichurumen/2013/0124/16760_3.html