Linux 使用core file文件快速定位程序崩溃代码行

问题描述

如果在 Linux下编写程序,有时运行程序的时候程序崩溃,比如说只有“Segmentation fault (core dumped) ”,程序比较小的话,还可以一行一行查看,但是如果程序很庞大,一行行查询,效率非常低下。Linux下可以程序可以生成core file文件,借助gdb很快能定位到崩溃的代码行。

解决方案

测试程序,除零操作,程序会崩溃

/*
test.c
*/
#include <stdio.h>
#include <stdlib.h>
int func(int a, int b)
{
    int c = a/b;
    return c;
}
int main()
{
    int a = 20;
    int b = 0;
    int ret = func(a,b);
    return 0;
}

第一步:设置core file的大小,设置成无限大

ulimit -c unlimited

第二步:把生成的core file 重定位到 自定义的目录下,比如说系统目录下的“/tmp”下,%e是可执行文件名称,%p是pid

echo "/tmp/core-%e-%p" > /proc/sys/kernel/core_pattern

第三步:生成可执行文件

gcc -o test -g test.c

第四步:利用gdb和core file定位到程序崩溃的那一行

gdb test /tmp/core-test-2488 

接下来生成下面的信息:

warning: Can‘t read pathname for load map: 输入/输出错误.
Reading symbols from /lib/tls/i686/cmov/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `./test‘.
Program terminated with signal 8, Arithmetic exception.
#0  0x080483c2 in func (a=20, b=0) at test.c:5
5       int c = a/b;

最后一行,出错的程序已经定位出来了。

参考资料

gdb结合coredump定位崩溃进程 - Ali’s Blog - 如你遇見這花 如我遇見你

http://lazycat.is-programmer.com/posts/31925.html

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-08-24 11:41:23

Linux 使用core file文件快速定位程序崩溃代码行的相关文章

linux设备驱动第四篇:从如何定位oops的代码行谈驱动调试方法

上一篇我们大概聊了如何写一个简单的字符设备驱动,我们不是神,写代码肯定会出现问题,我们需要在编写代码的过程中不断调试.在普通的c应用程序中,我们经常使用printf来输出信息,或者使用gdb来调试程序,那么驱动程序如何调试呢?我们知道在调试程序时经常遇到的问题就是野指针或者数组越界带来的问题,在应用程序中运行这种程序就会报segmentation fault的错误,而由于驱动程序的特殊性,出现此类情况后往往会直接造成系统宕机,并会抛出oops信息.那么我们如何来分析oops信息呢,甚至根据oop

Linux上Core Dump文件的形成和分析

原文: http://baidutech.blog.51cto.com/4114344/904419 Core,又称之为Core Dump文件,是Unix/Linux操作系统的一种机制,对于线上服务而言,Core令人闻之色变,因为出Core的过程意味着服务暂时不能正常响应,需要恢复,并且随着吐Core进程的内存空间越大,此过程可能持续很长一段时间(例如当进程占用60G+以上内存时,完整Core文件需要15分钟才能完全写到磁盘上),这期间产生的流量损失,不可估量. 凡事皆有两面性,OS在出Core

ubuntu下core file文件生成及调试

1.简介:corefile 是Linux下程序崩溃时生成的文件,可以用来分析程序崩溃的原因,因为它内部包含了程序崩溃时的堆栈信息. 2.corefile的设置 默认情况下,程序崩溃是不会生成corefile的,因为被操作系统限制.可以通过命令: ulimit -c 来查看,如果值为0则表示被限制了,所以不能生成corefile文件. 如果要使用corefile文件分析程序和系统异常信息,可以通过如下命令打开,其中unlimited表示corefile文件的大小无限制. $ ulimit -c u

VEH帮你定位程序崩溃地址

之前朋友有一个服务端程序,总是受到一些人的恶意漏洞攻击,没有源代码,只好反汇编修复了漏洞,并且使用WinLicense加保护授权. 漏洞总不是一次可以修复完的,恶意攻击并没有停止,然后加了WL保护程序在崩溃的时候在没有提示信息,服务器日志中也没有记录任何有用的信息了,这里所需要有用的信息即是崩溃时候汇编代码运行的内存地址.c++写的程序崩溃的时候我们经常可以看到这种包含了运行址,以及访问内存地址相关信息的对话框. 首先想到的办法是使用windbg的adplus -crash dump内存分析,c

在linux中导入sql文件的方法分享(使用命令行转移mysql数据库)

因导出sql文件 在你原来的网站服务商处利用phpmyadmin导出数据库为sql文件,这个步骤大家都会,不赘述. 上传sql文件 前面说过了,我们没有在云主机上安装ftp,怎么上传呢? 打开ftp客户端软件,例如filezilla,使用服务器IP和root及密码,连接时一定要使用SFTP方式连接,这样才能连接到linux.注意,这种方法是不安全的,但我们这里没有ftp,如果要上传本地文件到服务器,没有更好更快的方法. 我们把database.sql上传到/tmp目录. 连接到linux,登录m

Delphi通过Map文件查找内存地址出错代码所在行

什么是MAP文件       什么是 MAP 文件?简单地讲, MAP 文件是程序的全局符号.源文件和代码行号信息的唯一的文本表示方法,它可以在任何地方.任何时候使用,不需要有额外的程序进行支持.而且,这是唯一能找出程序崩溃的地方的救星.       如果要查找代码行号,需要使用下面的公式做一些十六进制的减法运算:       崩溃行偏移 = 崩溃地址(Crash Address) - 基地址(ImageBase Address) - 0x1000       为什么要这样做呢?我们得到的崩溃地

如何快速定位 Linux Panic 出错的代码行

问题描述 内核调试中最常见的一个问题是:内核Panic后,如何快速定位到出错的代码行? 就是这样一个常见的问题,面试过的大部分同学都未能很好地回答,这里希望能够做很彻底地解答. 问题分析 内核Panic时,一般会打印回调,并打印出当前出错的地址: kernel/panic.c:panic(): #ifdef CONFIG_DEBUG_BUGVERBOSE /* * Avoid nested stack-dumping if a panic occurs during oops processin

如何定位Release 版本中程序崩溃的位置 ---利用map文件 拦截windows崩溃函数

1       案例描述 作为Windows程序员,平时最担心见到的事情可能就是程序发生了崩溃(异常),这时Windows会提示该程序执行了非法操作,即将关闭.请与您的供应商联系.呵呵,这句微软的“名言”,恐怕是程序员最怕见也最常见的东西了. 在一个大型软件的测试过程中,初期出现程序崩溃似乎成了不可避免的事.其实测试中出现程序崩溃并不可怕,反而是测试的成功.作为开发的我们更需要关心的是程序中的哪个函数或哪一行导致了系统崩溃,这样才能有针对性的进行改正. 本文描述了自己总结的几种定位崩溃的办法.

结合程序崩溃后的core文件分析bug

结合程序崩溃后的core文件分析bug 引言 在<I/O的效率比较>中,我们在修改图1程序的BUF_SIZE为8388608时,运行程序出现崩溃,如下图1: 图1. 段错误 一般而言,导致程序段错误的原因如下: 内存访问出错,这类问题的典型代表就是数组越界. 非法内存访问,出现这类问题主要是程序试图访问内核段内存而产生的错误. 栈溢出, Linux默认给一个进程分配的栈空间大小为8M,因此你的数组开得过大的话会出现这种问题. 首先我们先看一下系统默认分配的资源: $ ulimit -acore