[Debug]用gdb分析coredump文件

1,系统默认是不产生coredump文件的,需要用以下命令使系统产生coredump文件

查看core文件的限制,此时为0,即不成生core文件

ulimit -c

0

打开core文件的限制,不限制core文件的大小,使程序可以产生core文件

ulimit -c unlimited

ulimit -c

unlimited

2,以下是内存访问错误示例

[cpp] view plaincopy

  1. 1 #include<stdio.h>
  2. 2 int main()
  3. 3 {
  4. 4      char* str = "hello";
  5. 5      str[0] = ‘H‘;
  6. 6      return 0;
  7. 7 }

3,通过以下命令编译:

gcc  demosegfault.c -o a.out -g

gdb a.out core

bt

 Core was generated by `./demoSegfault‘.
 Program terminated with signal 11, Segmentation fault.
 #0  0x0804835a in main () at demoSegfault.c:5
 5               str[0] = ‘H‘;
 (gdb) bt
 #0  0x0804835a in main () at demoSegfault.c:5
 (gdb)

1,coredump的概念
当一个程序崩溃时,OS会将该进程的的地址空间保存起来,然后通过工具(GDB,trace32)离线调试


2,coredump参数

/proc/sys/kernel/core_pattern (设置coredump的名称)
支持的参数
%p: 添加pid %u: 添加当前uid
%g: 添加当前gid
%s: 添加导致产生core的信号 %t: 添加core文件生成时的unix时间
%h: 添加主机名 %e: 添加命令名
ulimit -a (当core_pattern里有管道时忽略此参数) (设置coredump的大小)
可以用ulimit -c filesize(KB)改变大小
ulimit -c unlimited表示不设限
如果为0,表示不支持coredump
/proc/$pid/coredump_filter (设置允许coredump的内存)
支持的参数
bit0: 私有匿名 bit1: 共享匿名
bit2: 有底层文件的私有映射 bit3: 有底层文件共享映射
bit4: ELF头 bit5: 私有大尺寸页
bit6: 共享大尺寸页
默认值: 0x23

3..bat文件编写实例:
adb remount
 
adb shell echo "/system/coredump" > /proc/sys/kernel/core_pattern
adb shell echo 0x27 > /proc/self/coredump_filter
adb shell ulimit -c unlimited
 
adb shell /sbin/recovery
 
echo "wait 15s to pull coredump"
 
@echo off
ping -n 15 127.0.0.1>nul 
@echo on
 
adb pull /system/coredump

时间: 2024-10-14 21:02:07

[Debug]用gdb分析coredump文件的相关文章

用gdb分析core文件及常见gdb命令操作示例

1.概述 在实际的软件开发项目中,程序出现问题是在所难免的.遥想本人参加工作之后首次遇到程序的情景,至今还历历在目.之前的经验告诉我,我们越是惊慌失措,问题就越是解决不了.我们要先让自己平静下来,然后再寻找解决程序问题的办法. 在Linux下做开发的朋友,想必都与core文件打过交道.当看到自己的程序运行之后出现core时,很多人都慌乱了,仿佛天快要塌下来一样.其实,我们大可不必如此,只要我们掌握了用gdb调试core文件的办法,依然可以很快定位程序问题,一举将bug消灭掉.有关Linux co

使用GDB生成coredump文件【转载】

本文转载自: http://blog.csdn.net/sky_qing/article/details/8548989 如果在测试过程中遇到某个进程的CPU利用率过高或者卡死而需要去调试该进程时,可以利用gdb命令生成coredump文件,然后再去调试coredump文件来定位问题. 那么如何使用gdb生成coredump文件呢?其实步骤很简单: 1. 安装好gdb,然后使用命令 'gdb'.(假设需要调试的进程号为 21509) 2. 使用 ‘attach 21590’命令将gdb附加到进程

gdb调试coredump文件

linux上程序崩溃起来挺烦人,不过linux 比较好的是有gdb. 1.生成coredump文件 echo "ulimit -c unlimited" >> /etc/profile 然后记得敲入命令 source /etc/profile 然后敲入命令: ulimit –c 效果如下: 确认能否生成coredump文件,使用如下命令(使用时注意,我在测的时候会直接退出当前用户) kill -s SIGSEGV $$ 然后回到执行上述命令的路径下即可看到coredump文

Linux内核:分析coredump文件 - 内核代码崩溃

转自:http://blog.csdn.net/guowenyan001/article/details/12975221 一.分析Core文件 1.1 找到core文件目录,启动mycrash:mycrash 1.2 查看崩溃的堆栈信息:bt 1.3 反汇编崩溃点的代码,10行:dis -l extract_http_info+73 10 二.分析源文件hinfo.ko 2.1 查看源文件信息:objdump -S hinfo.ko > tmp 2.2 从tmp文件中查找1.3中的内容movb

Unix 用gdb分析core dump文件

产生core文件条件 用ulimit -c 指定core文件大小来开启core文件的生成,如:ulimit -c unlimited 用gdb分析core文件的条件 可执行程序在编译时,需加入-g参数,否则gdb无法找到symbol信息,从而无法定位问题. 例如,如下两个cpp文件中,test.cpp会导致crash. // test.cpp void testCrash() { int *p = 0; *p = 3; } // main.cpp #include <stdio.h> void

如何分析coredump

一,什么是coredump 我们经常听到大家说到程序core掉了,需要定位解决,这里说的大部分是指对应程序由于各种异常或者bug导致在运行过程中异常退出或者中止,并且在满足一定条件下(这里为什么说需要满足一定的条件呢?下面会分析)会产生一个叫做core的文件. 通常情况下,core文件会包含了程序运行时的内存,寄存器状态,堆栈指针,内存管理信息还有各种函数调用堆栈信息等,我们可以理解为是程序工作当前状态存储生成第一个文件,许多的程序出错的时候都会产生一个core文件,通过工具分析这个文件,我们可

linux系统产生和调试coredump文件

系统配置了coredump后,当程序异常终止时操作系统会在指定的目录下按指定的文件名格式产生一个core文件.core文件是程序内存映像以及相关的调试信息,通过gdb调试coredump文件可以知道导致程序异常终止的原因. 1.系统配置coredump 首先是打开coredump,通过ulimit命令看coredump是否开启: [[email protected] coredump]# ulimit -a core file size (blocks, -c) unlimited data s

GDB与coredump错误类文件的解析

GDB与coredump错误类文件的解析 GDB是Linux与UNIX系统下的一款程序调试工具,下面来介绍GDB的用法: 请先看这个程序: 这是我们作为实验的一个小程序,共10行输出4 进行编译如果要用GDB调试必须要加-g参数 这是编译好的文件的正常运行 开始调试这个程序 gdb 加文件名 现在介绍第一个参数l(list)就是如图这样显示程序的内容, l后还可以加数字,就是打印这个行数上下共10行. start程序开始单步调试,自动执行第一步. 参数b 设置断点就是程序函数到这一步暂停等待下一

gdb调试core文件

什么是Core Dump?Core的意思是内存, Dump的意思是扔出来, 堆出来.开发和使用Unix程序时, 有时程序莫名其妙的down了, 却没有任何的提示(有时候会提示core dumped). 这时候可以查看一下有没有形如core.进程号的文件生成, 这个文件便是操作系统把程序down掉时的内存内容扔出来生成的, 它可以做为调试程序的参考.core dump又叫核心转储, 当程序运行过程中发生异常, 程序异常退出时, 由操作系统把程序当前的内存状况存储在一个core文件中, 叫core