Linux提供了一个专门的变量$?来保存上个已执行命令的退出状态码.对于需要进行检查的命令,必须在其运行完毕后立刻查看或使用$?变量.它的值会变成由shell所执行的最后一条命令的退出状态码: [root@host1 test]# date 2017年 07月 19日 星期三 :: CST [root@host1 test]# echo $? 按照惯例,一个成功结束的命令的退出状态码是0.如果一个命令结束时有错误,退出状态码就是一个正数值(1-255): [root@host1 test]# q

当我们的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设置的函数,在

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

本文转自: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

#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

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

一.引言 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文件是进程的内存镜像,可以把程序运行时的状态

原文地址:http://blog.csdn.net/starlee/article/details/6618849 在我的那篇<让程序在崩溃时体面的退出之Unhandled Exception>中提供了一个捕捉程序崩溃事件的方法,可以添加代码在程序崩溃的时候做出适当的处理.不过,只知道程序在什么时候崩溃,但是不知道为什么崩溃,这对于程序开发者来说没有任何意义.因为如果不知道程序崩溃的原因,就没法去找到代码中的缺陷,当然就没法去修改代码而避免程序的崩溃.        所有调试过代码的开发者都知

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

[目的] 父进程使用os.waitpid()等待子进程退出,并检测子进程的exit code,以决定是否重启子进程. (常见的应用场景是:子进程接收外部命令,收到"stop"时退出所有进程,终止服务:收到"restart"时所有子进程退出,父进程重启所有子进程,以达到重启服务的目的). 这里面的关键点在于,子进程退出时设置exit code,父进程waitpid时获取该exit code,进而决定是否需要重启子进程. [问题] 子进程 ...#need restar

windows下C++程序release版本崩溃错误排查方法. 一个你精心设计的24小时不间断运行,多线程的程序,突然运行了几个月后崩了,此问题是非常难以排查的,也是很头疼的问题. 现利用Google开源工具crashrpt与Microsoft windbg工具,解决这个问题,并分享给大家. 使用工具Crashrpt.Windbg.因为windbg这个工具很常见,暂不介绍.其中重点介绍一下crashrpt. 一.crashrpt 简介 crashrpt是一个包含能够在程序出现各种类型未处理异常时

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

iOS开发中遇到程序崩溃是很正常的事情,如何在程序崩溃时捕获到异常信息并通知开发者,是大多数软件都选择的方法.下面就介绍如何在iOS中实现: 1. 在程序启动时加上一个异常捕获监听,用来处理程序崩溃时的回调动作  NSSetUncaughtExceptionHandler (&UncaughtExceptionHandler);  官方文档介绍:Sets the top-level error-handling function where you can perform last-minute

在应用发布以后,由于安卓机型的千差万别 ,可能会出现各种各样的问题,这时候如果我们可以将这些信息收集起来,并进行修改就很不错了.下面就来讨论一下怎么处理程序崩溃以后,错误信息的手机. Java中已经提供了一个接口Thread.UncaughtExceptionHandler来对运行时的异常进行处理.只需要实现这个接口,并覆写 public void uncaughtException(Thread thread, Throwable ex) 方法即可. 由于Application是Android

iOS 中捕获程序崩溃日志 (2014-04-22 17:35:59) 转载▼     iOS开发中遇到程序崩溃是很正常的事情,如何在程序崩溃时捕获到异常信息并通知开发者,是大多数软件都选择的方法.下面就介绍如何在iOS中实现: 1. 在程序启动时加上一个异常捕获监听,用来处理程序崩溃时的回调动作  NSSetUncaughtExceptionHandler (&UncaughtExceptionHandler);  官方文档介绍:Sets the top-level error-handlin

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

转自:http://www.tairan.com/archives/1143 欢迎回到当程序崩溃的时候怎么办 教程! 在这个教程的第一部分,我们介绍了SIGABRT和EXC_BAD_ACCESS错误,并且举例说明了一些使用xcode调试器(Xcode debugger)和异常断点(Exception Breakpoints)解决问题的策略. 但是我们的app仍然有一些问题!就像我们看到的,他工作的并不是很好,并且这里仍然有许多潜在的可能崩溃的问题. 幸运的是,在这个教程的第二部分,也是最后一部分