android coredump

我们开发Android本地可执行程序时，常常遇见segment fault错误，若程序比较复杂，使用打日志的方式很难查到出错的根本原因，若能让程序出core，然后用gdb 调试该core文件将能很快定位出错的代码位置，并能看到运行时出错代码的运行栈，这样能迅速定位。

1. core dump

那什么是core dump呢，core dump是指当程序运行崩溃的瞬间，内核会抛出当时该程序进程的内存详细情况，存储在一个core.xxx的文件中，Android默认设置情况下，程序运行出错后是不会出core的，需要进行以下设置：

• 1) 设置core文件的存储位置

  echo “/data/coredump/core.%e.%p” > /proc/sys/kernel/core_pattern

  表示存储在 /data/coredump 下，%e表示程序的名字，%p是指进程号， 示例：core.adbd.235

  若不设置core文件的存储位置，core文件将保存在程序运行时的工作目录下，文件名是core

  若想系统启动时自动设置core文件的存储位置(这样不用每次开机都需要重新设置),可以在根文件系统的init.rc里添加命令：

  on init ... write /proc/sys/kernel/core_pattern /data/coredump/core.%e.%p ...

• 2) 设置core文件大小限制

  默认情况下系统限制core文件大小为0，此时程序运行出错无法出core,若使用ulimit -c命令查看，可以看到结果是0，这时候可用ulimit -c unlimited 设置core文件大小无限制，此时运行程序出错后，便可以出Core了。但是请注意使用ulimit命令修改core限制，只针对此次会话有效，也就是说你使用adb shell 设置好后，在另外一个终端里运行adb shell后，再运行程序出错，还是不会出Core。

  若想对所有会话都有效，需要在系统启动时，就进行这样的设置。但是ulimit是一个shell内置命令，故此不能在init.rc里添加调用ulimit命令的服务来解决该问题，此时有三种解决方法，修改现有init.rc里的服务对应程序的源代码，或者修改init的源代码，或者编写一个本地程序，并在init.rc添加一个服务调用该程序，取消core文件大小限制的关键代码如下：

  1 2 3 4

  struct rlimit lim; lim.rlim_cur=RLIM_INFINITY; lim.rlim_max=RLIM_INFINITY; setrlimit(RLIMIT_CORE,&lim); //出core

  你可以将该段代码添加到你的本地程序里或者init源代码，或者服务程序源代码里。这样系统启动后，程序异常退出时，便会出core。此种方式对调试adbd程序非常有帮助。

2. 使用gdb调试出Core的程序

调试出现segment fault的本地程序时，别使用优化后的程序，这样使用gdb调试时不能看到源代码，都是一堆的二进制代码。Android源代码开发时，优化前的程序位于目录out/target/product/m7cdug/symbols下(m7cdwg是某个产品)，你可以在该目录下使用find 命令查找你要调试的程序: find -name “progname”。

程序出core后，使用adb pull将core文件从手机上拉下来，再将该文件放置到源代码开发主机的优化前程序所处目录下。如果你在编译Android源代码，并使用了source build/envsetup.sh，此时在编译源代码的终端可以运行arm-eabi-gdb命令来调试core文件，若找不到该命令，先将该命令所在目录添加到PATH目录。调试core文件的命令：arm-eabi-gdb 被调试程序 core，示例:

1	arm-eabi-gdb adbd core.adbd.235

注意:

使用该命令时，可能会出现问题：libpython2.6.so.1.0: cannot open shared object file，此时需要安装 python 2.6

先下载python 2.6并解压，http://www.python.org/ftp/python/2.6/Python-2.6.tar.bz2

编译并安装

./configure --prefix=/opt/python26 --enable-shared --enable-unicode=ucs4 #安装至/opt/python26 make && sudo make install sudo ln -s /opt/python26/lib/libpython2.6.so.1.0 /usr/lib/libpython2.6.so.1.0 #软链接

调试时比较常用的命令：

bt：查看异常时的堆栈，使用gdb调试Core文件时，一般用该命令先查看出错的源代码位置

list: 查看当前堆栈指针指向的源代码的前后共10行代码

up n: 堆栈指针往上移动n层

down n:堆栈指针往下移动n层

frame: 查看堆栈指针指向当前堆栈的位置

print: 查看某个变量 示例：print a

from:  http://www.cloudchou.com/android/post-307.html

http://m.blog.csdn.net/blog/handyhuang/17010489#

#000

   保证开发板，windows主机，linux虚拟机 3者互联互通

   linux虚拟机 ip 192.168.1.100

   windows主机ip 192.168.1.102

   linux开发板 ip 192.168.1.103(eth0) 

#001 NFS调试

   linux虚拟机
   /etc/exports 文件增加一行 /your/board_rootfs/path/ROOTFS*(rw,sync,no_root_squash)
   /etc/init.d/nfs restart 重启nfs服务
   将编译好的板子程序 app_test，拷贝到/your/board_rootfs/path/ROOTFS/root/

   linux开发板
    设置启动参数，不同开发版有差异，重点在紫色和蓝色部分
     setenv bootargs 'console=ttyS0,115200 root=/dev/nfs rwnfsroot=192.168.1.100:/your/board_rootfs/path/ROOTFSip=192.168.1.103::192.168.1.1:255.255.255.0::eth0:LX_MEM=0x2300000EMAC_MEM=0x100000 DRAM_LEN=0x10000000 LX_MEM2=0BB_ADDR=0xFFFFF00,0MS_GOP0_MIU=0 mtdparts=edb64M-nand:120m(UBI),-(NA)'

   saveenv 

    重启开发板，等待开发板挂载linux虚拟机里的根文件系统，成功后，可以通过SecureCRT等软件登录到开发板
     cd /root/
     ./app_test
      就可以运行app_test程序,另外可以按需修改开发板的/etc/init.d/rcS文件

#002 程序崩溃产生core文件

   linux开发板
    运行app_test前，执行如下指令
     ulimit -c unlimited
     如果程序崩溃没有core文件，可以确认是内核问题。例如mstar的开发板，必须在/application下面执行才生成core文件。程序崩溃后，在app_test同级目录产生Coredump.gz 文件 

   linux虚拟机
    gzip -d Coredump.gz （此命令解压Coredump.gz后产生Coredump文件，自动删除掉Coredump.gz）
     /opt/mstar/mips-4.3/bin/mips-linux-gnu-gdb -c Coredump  app_test
     setsolib-search-path/your/board_rootfs/path/ROOTFS/lib
     core-file
     core-fileCoredump
     bt

    就会看到崩溃的堆栈信息