当我们的linux程序崩溃的时候,常常会有这样的提示:    Segmentation fault (core dumped)    段错误 (核心已转储)    提示说生成了core文件,但是此功能常常是默认关闭的,并没有产生core文件.    查看方法是:    ulimit -c         打开此功能,仅本次登录有效:    ulimit -c unlimited        默认生成的都叫core,新的覆盖旧的.    自动加pid后缀:    echo "1" &g

今天在浏览张队转载文章的留言时,遇到一个读者问了这样的问题,如下图所示: 首先能明确的一点是"程序崩溃退出了是不能用常规的方式dump的",因为整个进程树都已经退出.现场已经无法使用常规的方式读取到. 一般来说常规的方法是没办法读取到的,也有一些特殊的方式,比如有关部门在调查取证时,就可以通过一些工具读取到内存中的信息.当然这是一些hack手段,不在本文讨论中. 不过好消息是,虽然您无法在程序崩溃退出以后创建Dump,但是您可以在程序崩溃时自动创建Dump,这样下次遇到程序崩溃,那么就

关于程序崩溃时转储内存DMP,可以设置注册表,使程序崩溃时自动转储内存DMP,见程序崩溃时利用注册表自动转储内存DMP.本文要介绍的是使用SetUnhandledExceptionFilter函数在程序崩溃时取得程序内存DMP,并解决一些困扰人的问题. 从名字上就可以看出SetUnhandledExceptionFilter的作用就是设置未捕获异常函数,程序崩溃就是因为有些异常我们没有捕获,而当这些异常我们没捕获时,系统就会调用SetUnhandledExceptionFilter设置的函数,在

程序异常退出  却没有产生core文件 http://www.cnblogs.com/my_life/articles/4107333.html

/* 不限制 core 文件的大小 */ ulimit -c unlimited /* 使用 pid 进行命名 */ echo " > /proc/sys/kernel/core_uses_pid /* 配置 core 文件存储路径,及名称的格式 */ echo "~/corefile/core-%e-%p-%t" > /proc/sys/kernel/core_pattern

Android系统的"程序异常退出",给应用的用户体验造成不良影响.为了捕获应用运行时异常并给出友好提示,便可继承UncaughtExceptionHandler类来处理.通过Thread.setDefaultUncaughtExceptionHandler()方法将异常处理类设置到线程上即可. 写一个例子来理解. 1.新建项目,新建一个MyCatchException类,实现uncaughtExceptionHandler. //全部错误捕捉器 public class MyCatc

#include <DbgHelp.h> //生产DUMP文件 int GenerateMiniDump(HANDLE hFile, PEXCEPTION_POINTERS pExceptionPointers, PWCHAR pwAppName) { BOOL bOwnDumpFile = FALSE; HANDLE hDumpFile = hFile; MINIDUMP_EXCEPTION_INFORMATION ExpParam; typedef BOOL(WINAPI * MiniDu

本文转自:http://www.cnblogs.com/dabaopku/archive/2011/07/04/2097029.html 尤其是使用visual studio开发程序 ,自己特意throw一个exception,每次都被它先捕捉到,等上10秒种才轮到vs调试器,甚是烦人. 关闭这个鸡肋的功能很简单,可惜隐藏的太深. 控制面板=>操作中心=>维护右边的箭头,打开隐藏的子窗口=>检查问题报告解决方案 选择设置,选择上那个不推荐设置就行了. 终于可以立即崩溃 了.

使用代码手工生成dmp文件 SetUnhandledExceptionFilter 为每个线程设置SetUnhandledExceptionFilter(MyCallBack),(必须在每个线程中启动时调用一次,否则造成无法进入回调函数中)这样该线程中发现未处理的 SEH 异常时就会进入到MyCallBack 回调中. 无聊的是虽然MyCallBack 的参数是 SEH 异常的结构体指针,但 C++异常也会进入到MyCallBack 中.所以只要SetUnhandledExceptionFilt

http://blog.csdn.net/lanmolei814/article/details/45201693 ====================================== 1.Core文件简介 Core文件其实就是内存的映像,当程序崩溃时,存储内存的相应信息,主用用于对程序进行调试.当程序崩溃时便会产生core文件,其实准确的应该说是core dump 文件,默认生成位置与可执行程序位于同一目录下,文件名为core.***,其中***是某一数字. 2.开启或关闭Core文件

gdb-7.2-64.el6_5.2.x86_64/usr/bin/gcore/usr/bin/gdb/usr/bin/gdb-add-index/usr/bin/gdbtui/usr/bin/gstack/usr/bin/pstack [root@coreserv tmp]# rpm -qa|grep abrabrt-libs-2.0.8-6.el6.centos.x86_64abrt-addon-ccpp-2.0.8-6.el6.centos.x86_64abrt-2.0.8-6.el6.c

Core文件简单介绍及生成设置方法 Core文件其实就是内存的映像,当程序崩溃时,存储内存的相应信息,主用用于对程序进行调试.当程序崩溃时便会产生core文件,其实准确的应该说是core dump 文件,默认生成位置与可执行程序位于同一目录下,文件名为core.***,其中***是某一数字. 1.文件大小限制(开关) (1)临时性设置 查看core文件是否生成: $ulimit -c  可以查看是否打开此选项,若为0则为关闭: ulimit -c 0可手动关闭 打开core文件生成: $ulim

前面转载了一篇文章关于core文件的产生和调试使用的设置,但在使用有一些需要注意的问题,如 在什么情况 才会正确地产生core文件. 列出一些常见问题: 一,如何使用core文件 1. 使用core文件 在core文件所在目录下键入: gdb -c core 它会启动GNU的调试器,来调试core文件,并且会显示生成此core文件的程序名,中止此程序的信号等等. 如果你已经知道是由什么程序生成此core文件的,比如MyServer崩溃了生成core.12345,那么用此指令调试: gdb -c

原文链接:http://team.eyou.com/?p=27 如有侵犯您的版权,请联系windeal12@qq.com linux下,产生core文件,和不产生core文件的条件: 当我们的程序崩溃时,内核有可能把该程序当前内存映射到core文件里,方便程序员找到程序出现问题的地方.最常出现的,几乎所有C程序员都出现过的错误就是"段错误"了.也是最难查出问题原因的一个错误.下面我们就针对"段错误"来分析core文件的产生.以及我们如何利用core文件找到出现崩溃的

浅析Linux下core文件 当我们的程序崩溃时,内核有可能把该程序当前内存映射到core文件里,方便程序员找到程序出现问题的地方.最常出 现的,几乎所有C程序员都出现过的错误就是"段错误"了.也是最难查出问题原因的一个错误.下面我们就针对"段错误"来分析core文件的产生.以及我们 如何利用core文件找到出现崩溃的地方. 何谓core文件 当一个程序崩溃时,在进程当前工作目录的core文件中复制了该进程的存储图像.core文件仅仅是一个内存映象(同时加上调试信息

在Linux下产生并调试core文件 先看看我用的是个什么机器: $ uname -aLinux dev 2.4.21-9.30AXsmp #1 SMP Wed May 26 23:37:09 EDT 2004 i686 i686 i386 GNU/Linux 再看看默认的一些参数,注意core file size是个0,程序出错时不会产生core文件了. $ ulimit -acore file size (blocks, -c) 0data seg size (kbytes, -d) unl

一.引言 dump文件是C++程序发生异常时,保存当时程序运行状态的文件,是调试异常程序重要的方法,所以程序崩溃时,除了日志文件,dump文件便成了我们查找错误的最后一根救命的稻草.windows程序产生dump文件和linux程序产生dump文件的方式不一样,linux默认是不让产生core dump文件,只要在用户自己的~/.bash_profile文件中增加 ulimit -S -c unlimited > /dev/null 2>&1 这样程序崩溃就可以产生可调试的core d

原文地址:http://blog.csdn.net/starlee/article/details/6630816 在我的那篇<让程序在崩溃时体面的退出之CallStack>中提供了一个在程序崩溃时得到CallStack的方法.可是要想得到CallStack,必须有pdb文件的支持.但是一般情况下,发布出去的程序都是Release版本的,都不会附带pdb文件.那么我们怎么能在程序崩溃的时候找到出错的具体位置呢?这个时候就该Dump文件出场了!Dump文件是进程的内存镜像,可以把程序运行时的状态

         在我的那篇<让程序在崩溃时体面的退出之CallStack>中提供了一个在程序崩溃时得到CallStack的方法.但是要想得到CallStack,必须有pdb文件的支持.但是普通情况下,公布出去的程序都是Release版本号的,都不会附带pdb文件.那么我们怎么能在程序崩溃的时候找到出错的详细位置呢?这个时候就该Dump文件出场了!Dump文件是进程的内存镜像,能够把程序执行时的状态完整的保存下来.         要想在程序崩溃的时候创建Dump文件,就须要用到DbgHelp

使用MAP文件快速定位程序崩溃代码行 =========================================================== 作者: lzmfeng(http://lzmfeng.itpub.net)发表于:2006.04.19 17:16分类: 摆脱程序 出处:http://lzmfeng.itpub.net/post/15253/70530-------------------------------------------------------------