Android中用gdb调试一启动就崩溃的程序

一般情况下程序是在某一个点挂掉的，我们可以用adb shell ps查到PID，然后在target端用gdbserver attach上去，最后在host端用gdb连上去调。但程序往往不会崩溃得这么完美，很多情况下程序一起来就crash掉了。这个时候分两种情况：1.真的是一起来就挂掉的。2.一起来后稍稍过会就挂掉的。

这里我用的系统是：
Host: Ubuntu x64
Target: Android ICS

方法一：针对第一种情况。首先在target的Android中运行Dev Tools->Development Settings，点按钮"None"选择你要调的程序（这里比如是flashplayer），然后选中Wait for debugger就可以退出了。



这时候打开要调的程序就会停住：


  

当然，这时候wait for debugger不是wait gdb，是DDMS。但因为我们最后是用gdb调，所以这时候要趁机用gdb attach上去。具体gdb的设置和使用请参见另一博文（http://www.atcpu.com/kf/201203/124820.html）。一般情况下你会看到类似于下面的东西：
jzj@jzj-laptop:~/debug$ gdb -x init.gdb
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
...
__futex_syscall4 () at bionic/libc/arch-x86/bionic/atomics_x86.S:73
73     popl    %esi
Created trace state variable $trace_timestamp for target's variable 1."
(gdb)
gdb启动后就可以设断点啊看变量什么的了，设好断点后输入continue继续运行，但就像前面提到的wait for debugger不是wait gdb，所以gdb说continue还不能continue。打开DDMS


有个红色虫子表示停住了，点上面绿色虫子程序就可以继续运行程序了。然后就可以换由gdb控制，尽情调试了。

方法二：针对第二种情况。用脚本启动目标程序，然后马上attach上去。脚本总比人肉输入快，所以有时候可以用这个方法拼一下看是先crash还是先attach上，优点是比较简单。下面是个简单的例子（调的是Adobe reader），注意其中的grep的字符串得看情况而定，现实当中用时可以先把PID打印出来，或者自动判断下是否唯一。
#!/bin/bash
ACTION=Android.intent.action.MAIN
COM=com.adobe.reader/com.adobe.reader.AdobeReader
adb root
adb shell am start -a $ACTION -n $COM
PID=`adb shell ps | grep "reader" | awk '{print $2}'`
CMD="adb shell /data/gdbserver :1234 --attach $PID"
echo $CMD
eval $CMD