进程运行环境分析

1. 系统运行环境
当我们怀疑死机问题可能是某个进程出现问题而引发时，通常我们需要对这个进程进行深入的分析, 即进程运行环境分析。通常包括分析如，线程状态，各种变量值，寄存器状态等。在Android 系统中，我们将其划分成三个层次。
即 Java 运行环境分析, Native 运行环境分析, Kernel 运行环境分析. 下面分别说明.

2. Java 运行环境分析
我们对于Zygote fork 出来的process, 如APP 以及system_server, 都会进行Java 运行环境分析. 其关键是分析Java Heap, 以便快速知道某个Java 变量的值, 以及Java 对象的分布和引用情况。
通常Java Heap 的分析方式则是抓取Java Hprof, 然后使用MAT 等工具进行分析.
* 抓取Hprof 的手法，如:
第一种方式: 使用am 命令
    adb shell am dumpheap {Process} file
    如： 
 adb shell chmod 777 /data/anr
 adb shell am dumpheap com.android.phone /data/anr/phone.hprof
    adb pull /data/anr/phone.hprof
 
第二种方式: 使用DDMS 命令
    在DDMS 中选择对应的process, 然后在Devices 按钮栏中选择Dump Hprof file， 保存即可
 
第三种方式: 通过代码的方式
    在android.os.Debug 这个class 中有定义相关的抓取hprof 的method.
 如: public static void dumpHprofData(String fileName) throws IOException;
 这样即可在代码中直接将这个process 的hprof 保存到相对应的文件中，注意这个只能抓取当时的process.
 如果想抓其他的process 的hprof, 那么就必须通过AMS 帮忙了。
 可以先获取IActivityManager 接口，然后调用它的dumpheap 方法。具体的代码，大家可以参考
 frameworks/base/cmds/am/src/com/android/commands/am/am.java 中的调用代码
 
第四种方式: 发送SIGUSER1 
    在部分机器中，如果具有root 权限，可以直接发送SIG 10 来抓取, 此时对应的Hprof 保存在/data/misc下面，文件名如：
 heap-dump-tm1357153307-pid1882.hprof
 
* 快速分析
首先, DVM 的Hprof 和 标准的Java Hprof 有一些差别, 需要使用hprof-conv 进行一次转换, 将DVM 格式的hprof 转换成标准的java 命令的hprof
    hprof-conv in.hprof out.hprof

其次, 使用如MAT Tool, 打开转换后的hprof 文件, 通常我们会
 analysis  java thread information
 analysis  java var value
 analysis  Object reference
 analysis  GC path
具体如何使用MAT 分析可以参考MAT 的官方网站.

 

3. Native 运行环境分析
Native 运行环境分析，我们通常会采用Core dump 分析手法. Core dump 纪录了当时进程的各类关键资讯，比如变量参数，线程stack, heap, register 等。通常可以认为是这个Process 当时最为完整的资讯了。 但Core dump 往往比较大, 有时甚至会超过1G, 属于比较重量型的分析手法了。
* 如何抓取Core Dump.
   目前MTK 的机器会将Core Dump 转换成AEE DB. 否则对应的Core dump 文件即存放在/data/core 目录下
   手工抓取时, 可以：
   adb shell aee -d coreon
   adb shell kill -31 PID
   此时core dump 就可能存放在两个目录下: /data/core, 以及 /sdcard/mtklog/aee_exp 下面新的DB 文件.

* 如何分析Core Dump.
  因为通常已经将Core Dump 转换成了AEE DB. 所以首先将AEE DB 解开, 即可以看到PROCESS_COREDUMP 的文件，有的时候此文件很大, 比如超过1G.
  而分析Core Dump 的Tools 很多, 比如traces32, GDB 等，这里就不详加说明，可以参考网络上的相关文档.

 

4. Kernel 运行环境分析
从82平台上多了ramdump功能，可以发生KE后将82/92的物理内存压缩保存到EMMC的内置卡(默认保存到EMMC内置卡上)(92可以选择外置t卡)上，拿到该文件后就可以转换为kernel space，查看kernel各种变量，比查看kernel log更加方便快捷.
只有在eng版本下支持该功能，并且是EMMC的，存在内置T卡才行,
在projectConfig.mk里的MTK_SHARED_SDCARD必须为no即MTK_SHARED_SDCARD=no
连上adb后：
adb shell
#echo Y > /sys/module/mrdump/parameters/enable
#echo emmc > /sys/module/mrdump/parameters/device  (注意82只能在EMMC内置t卡上，不能下这条命令，92可以下这条命令修改到sdcard：#echo sdcard > /sys/module/mrdump/parameters/device)
这样就开启了ramdump功能，注意重启后无效，必须重新设置才行

之后重新开机，此时会在
内置T卡：/storage/sdcard0/
或外置T卡：/storage/sdcard1/
看到CEDump.kdmp文件，结合kernel/out/vmlinux或out/target/product/$proj/obj/KERNEL_OBJ/vmlinux一起提供给Mediatek即可做进一步kernel异常重启的分析.