1. 打开 core dump 查看是否打开 ulimit -c 如果输出0, 说明没有打开. 方法一:使用命令 ulimit -c unlimited 可以打开,但是只对当前终端有效, 方法二: 配置 /etc/profile 文件 sudo gedit /etc/profile 在最后添加一行 ulimit -S -c unlimited > /dev/null 2>&1 可以始终打开core dump , unlimited 可以改为具体的数字,比方说 1024 来限制 core

今天面试被问到一个问题,如何调试多进程的程序,我回答gdb attach [pid],之后又问如果程序中有些数据读取不对,但这种现象是偶然发生的,这时候要怎么操作,当时就懵了......,通过查找资料找到了答案,现在写篇博文记下来. checkpoint 有些时候bug的出现是偶然发生的,如果有东西可以保存当前的状态就好了:在GDB中使用checkpoint, GDB可以保存那一刻的程序状态或者说是程序映像(除了进程号和已经输出的内容),并且可以再次返回到那个程序的状态:每个checkpoint

abrt:Automatic bug detection and reporting tool https://github.com/abrt/abrt 常用的命令: abrt-auto-reporting abrt-cli 配置文件: /etc/abrt/abrt.conf /etc/abrt/abrt-action-save-package-data.conf 一般来讲,abrt直接就能用,直接就能查看coredump信息. 但是,当处理我们自己写的程序时,仍然不能用. 关系到下面的两个配置

最近在Linux环境下做C语言项目,由于是在一个原有项目基础之上进行二次开发,而且项目工程庞大复杂,出现了不少问题,其中遇到最多.花费时间最长的问题就是著名的“段错误”(Segmentation Fault).借此机会系统学习了一下,这里对Linux环境下的段错误做个小结,方便以后同类问题的排查与解决. 1. 段错误是什么 一句话来说,段错误是指访问的内存超出了系统给这个程序所设定的内存空间,例如访问了不存在的内存地址.访问了系统保护的内存地址.访问了只读的内存地址等等情况.这里贴一个对于“段错

1 出现core dump时最好的办法是使用gdb查看coredump文件 2 使用的条件 出现问题的代码,系统,所有涉及的代码都应该一起编译,然后得到符号表,这样加载符号表,使用coredump文件才有意义. 3 什么是段错误,有哪些原因会导致段错误 当访问了错误的地址时,就会发生段错误.之所以叫段错误,是因为只读数据段.代码段和操作系统所属的地址空间是不可以写的,因为拿到了指针可以做任何事情,不小心就写了.为了避免错误代码影响系统中的其它人,mmu和操作系统就会发出一个段错误给引起错误的进程

来自:http://blog.ddup.us/?p=176 写C/C++程序经常要直接和内存打交道,一不小心就会造成程序执行时产生Segment Fault而挂掉.一般这种情况都是因为数组越界访问,空指针或是野指针读写造成的.程序小的话还比较好办,对着源代码仔细检查就能解决.但是对于代码量 较大的程序,里边包含N多函数调用,N多数组指针访问,这时想定位问题就不是很容易了(此时牛人依然可以通过在适当位置打printf加二分查找的方式迅 速定位:P).懒人的话还是直接GDB搞起吧. 神马是Core

gdb 调试coredump文件过程: 第一步:首先需要一个进程的coredump文件,怎么搞出coredump文件呢? 1. ps -fax|grep                 进程名称 找到进程的pid 2.gdb -p pid                     调试进程 3.gcore coredump名称        则生成core文件 第二步:找出coredump文件的应用程序 1.gdb -c corefile   使用gdb调试core文件 2.info auxv  

知识共享许可协议本作品采用知识共享署名 4.0 国际许可协议进行许可.转载保留声明头部与原文链接https://luzeshu.com/blog/gdb-bug 本博客同步在http://www.cnblogs.com/papertree/p/6298774.html 在用qemu + gdb 调试linux内核时,遇到一个gdb的bug:"Remote 'g' packet reply is too long" ,记录一下. 1. 实验环境 1. qemu 版本: luzeshu@l

第一步:首先需要一个进程的coredump文件,怎么搞出coredump文件呢? 1. ps -fax|grep                 进程名称 找到进程的pid 2.gdb -p pid                     调试进程 3.gcore coredump名称        则生成core文件 第二步:找出coredump文件的应用程序 1.gdb -c corefile   使用gdb调试core文件 2.info auxv          索引31对应的是core

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

生活中有这么一种现象:如果你关注某些东西,它就会经常出现在你眼前,例如一个不出名的歌手的名字,一种动物的卡通形象,某个非常专业的术语,等等等等.这种现象也叫做“孕妇效应”.还有类似的一种效应叫做“视网膜效应”,它讲的是:你有什么东西或者特质你就特别容易在别处发现你有的这类东西和特质.干了多年测试的我就会经常发现日常使用的系统中有很多的bug,而我老婆就发现不了.今天要说的事儿是“重现难以重现的bug”,这件事儿在本周共遇见了4次:第一次是微博上有一篇<程序员,你调试过的最难的 Bug 是?>(

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

bug已经成为程序员工作中的一部分,作为从事嵌入式软件开发已有三年的我,经手的bug也不少了.先说说自己对于bug的心态变化吧,刚开始工作的时候,自己还是很喜欢bug的.那时,自己是负责维护别人的代码,如果发现了bug,说明自己工作有成绩:后来,自己开始码代码,这个时候测试人员告诉我有bug,自己就有些心烦,尤其是当领导知道了这个bug以后,就会感到很大压力:再后来,经手的bug变多了,也变得淡定多了,而且还逐渐建立自己分析bug的工具箱和分析流程:现在,经过几年的工作,积累了一些经验,开始在设

当GDB无法显示so动态库的信息或者显示信息有误时,通常是由于库搜索路径错误导致的,可使用set sysroot.set solib-absolute-prefix.set solib-search-path来指定库搜索路径. 1. set sysroot 与 set solib-absolute-prefix 是同一条命令,实际上,set sysroot是set solib-absolute-prefix 的别名. 2. set solib-search-path设置动态库的搜索路径,该命令可

用gdb调试程序笔记: 以段错误(Segmental fault)为例[转] 1.背景介绍2.程序中常见的bug分类3.程序调试器(如gdb)有什么用4.段错误(Segmental fault)介绍5.gdb调试入门 一.背景介绍这个笔记主要介绍开源的程序调试器(gdb)的入门知识,目的是使unix/linux环境的编程新手能够快速学会使用gdb调试程序的方法,同时也是对我使用gdb的一个经验总结.本文假设你能使用简单的unix/linux命令并能用gcc(GNU C Compiler, GNU

二次开发本来就是很恶心的事,我竟然是三次开发. 今天遇到一个BUG,上传图片的时候报错了,操作过程很简答,点击上传按钮,选择图片,确定上传,如图: 报错信息很直白,也很奇怪: (为了写博客,把代码回滚复现BUG,后台应该不会发现吧) 总之,报错很直白,语法错误,Sizzle引擎解析失败,抛出错误.我好歹也是看过jq源码的人啊,Sizzle引擎报错是传入了异常的Selector,目测就是#号后面那个function.WTK????我上传个图片为啥会$一个函数? 一脸懵逼的开始调试,好在老项目,代码

1.gdb和gdbserver调试原理 通过linux虚拟机里的gdb,来向开发板里的gdbserver发送命令,比如设置断点,运行setp等,然后开发板上的gdbserver收到命令后,便会执行应用程序做相应的动作,来实现调试的功能 和之前学的裸板GDB调试一样,只不过之前学的是在win下的,本次是在linux里的gdb 1.1同样,它们都会需要一个带调试信息的编译文件. 通过Makefile里的arm-linux-gcc  -g 来的,     -g:表示编译文件里包含gdb调试信息 1.2

你一定遇到过,一个很久没修改过的功能,莫名其妙的出现了问题?肉眼查代码.屡逻辑完全找不到问题点?前两天还好好的功能,怎么这个今天就不行了?这两天改动了这么多代码,到底是那一次改动引发的 Bug? 这样非崩溃的 Bug,有时候想要排查出问题,并不是一件容易的事情.我想,这个时候你会需要 git bisect ! 一.git bisect 基础使用 git bisect 是 Git 提供的一种 二分法 的调试工具,它可以按照我们选定的提交,进行二分分割,快速定位出出错的提交.来帮我们缩小最小改动的代

GDB是linux下的调试利器,在c/c++程序开发过程中必不可少的.这里总结一下多进程和多线程的调试方法和技巧. 多进程的调试: 如下示例 #include <sys/mman.h> #include <sys/stat.h> #include <fcntl.h> #include <unistd.h> #include <stdio.h> #include <stdlib.h> ; void test() { ; printf(&

为了避免小程序在开发运行之后出现"bug"无法知晓,Fundebug研发的小程序bug监控服务作为小程序的运维中心,很好的解决了这个问题. 该插件可以监控小程序中的所有函数调用: 通过记录出错前的函数调用序列,可以帮助用户快速准确地复现BUG,提高Debug效率. 支持多种属性配置 比如,systemInfo是用户的系统信息,比如操作系统,微信版本等等. "systemInfo": { "system": "iOS 10.2"