找到 android core dump 的 位置

這一篇有說明如何從 core dump 找到當機的 source code:
http://kobablog.wordpress.com/2011/05/14/how-to-read-crash-dump-of-android/

大概就是..從 out/target/product/XXX/ 下的 symbols folder，有 not stripped version 的檔案。

利用 objdump 列出位址與 source code。
配合 core dump 的內容就可以找出來了。

---

馬上來照著做好了，sample 是會發生 core dump 的XXXX..
內容大概是.. I/DEBUG ( 2333): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000 I/DEBUG ( 2333): r0 bee91054 r1 00000000 r2 bee9105a r3 00000000 I/DEBUG ( 2333): r4 bee91030 r5 bee91054 r6 80204c50 r7 0000abd8 I/DEBUG ( 2333): r8 bee91288 r9 4850cc70 10 0000abd8 fp aca9f368 I/DEBUG ( 2333): ip 80204c7c sp bee91028 lr 80201ec9 pc afd20856 cpsr 60000030 I/DEBUG ( 2333): #00 pc 00020856 /system/lib/libc.so I/DEBUG ( 2333): #01 pc 00001ec4 /data/data/com.Xingtek/lib/libhashkey.so I/DEBUG ( 2333): #02 pc 00011e34 /system/lib/libdvm.so I/DEBUG ( 2333): #03 pc 000436e0 /system/lib/libdvm.so I/DEBUG ( 2333): #04 pc 00048e62 /system/lib/libdvm.so I/DEBUG ( 2333): #05 pc 00017034 /system/lib/libdvm.so I/DEBUG ( 2333): #06 pc 0001c0e4 /system/lib/libdvm.so I/DEBUG ( 2333): #07 pc 0001afdc /system/lib/libdvm.so I/DEBUG ( 2333): #08 pc 00059dde /system/lib/libdvm.so I/DEBUG ( 2333): #09 pc 00061b52 /system/lib/libdvm.so I/DEBUG ( 2333): #10 pc 00017034 /system/lib/libdvm.so I/DEBUG ( 2333): #11 pc 0001c0e4 /system/lib/libdvm.so I/DEBUG ( 2333): #12 pc 0001afdc /system/lib/libdvm.so I/DEBUG ( 2333): #13 pc 00059c40 /system/lib/libdvm.so I/DEBUG ( 2333): #14 pc 00046126 /system/lib/libdvm.so I/DEBUG ( 2333): #15 pc 0003194e /system/lib/libandroid_runtime.so I/DEBUG ( 2333): #16 pc 000327fa /system/lib/libandroid_runtime.so I/DEBUG ( 2333): #17 pc 00008cca /system/bin/app_process I/DEBUG ( 2333): #18 pc 00014b52 /system/lib/libc.so 所以去查一下 libc.so 的 20856 ..
用 arm-eabi-objdump -S libc.so 之後，找 20856:

	00020848 <strcat>:
	char *
	strcat(char *s, const char *append)
	{
	char *save = s;
	for (; *s; ++s);
	20848: b510 push {r4, lr}
	2084a: 4602 mov r2, r0
	2084c: e000 b.n 20850 <strcat+0x8>
	2084e: 3201 adds r2, #1
	20850: 7813 ldrb r3, [r2, #0]
	20852: 2b00 cmp r3, #0
	20854: d1fb bne.n 2084e <strcat+0x6>
	while ((*s++ = *append++) != '\0');
	20856: 5ccc ldrb r4, [r1, r3]
	20858: 54d4 strb r4, [r2, r3]
	2085a: 3301 adds r3, #1
	2085c: 2c00 cmp r4, #0
	2085e: d1fa bne.n 20856 <strcat+0xe>
	return(save);
	}
	20860: bd10 pop {r4, pc}
	20862: bf00 nop

view raw gistfile1.asm hosted with ❤ by GitHub

可以看到是strcat( ) 中的... 20856: 5ccc ldrb r4, [r1, r3]
應該是 r1 是 00000000，也就是 strcat 的 pointer 有一個是 0導致。

去看一下 bionic/libc/string/strcat.c:

char * strcat(char *s, const char *append) { char *save = s; for (; *s; ++s); while ((*s++ = *append++) != '\0'); return(save); } 果然沒有檢查，
所以加上 null pointer 檢查。

奇怪的是，如果直接在 code 用 s, append 檢查，會被 optimize 掉，
所以要另開 function..
int isnotvalid(int a, int b) { if((a==0)||(b==0)) return 1; else return 0; } 然後在 strcat 壹開始用 isnotvalid( ) cheeck s, append 才不會被 optimize 掉，
兒這樣，那個 XingTek 的 apk 也可以執行了 (雖然沒值...)

---

附帶提一點（或許對其他人來說，已經是 common sense ..)

libc.so 好像是啟動就cache 住，所以用 adb sync 把修改過的 lib.so sync 到 target，再啟動XingTek app
他也不會使用新的 lib.so，

adb sync 玩 libc.so 後，要 system reboot 才行。