1.dump文件 2.程序对应的pdb 步骤一:安装windbg 步骤二:通过windbg打开crash dump文件 步骤三:设置pdb文件路径,即符号表路径 步骤四:运行命令!analyze -v,这是windbg提供的一个自动分析命令,正常情况下,会显示出导致崩溃的行为,其所在文件,以及其在文件中的具体行数 0:254> !analyze -v ..............(一些warnning信息)FAULTING_IP: GDrvStd!memcpy+b6007642b6 f3a5  

前言: 对于需要长时间运行的.net程序,有时需要我们查看内存的使用有没有内存泄露问题. 我们可以从dump文件中找到答案. Dump的看点 用dump文件来分析内存,到底我们需要关心哪些点呢? 内存的使用情况 HeapSize/object的数量 也就是托管堆使用大小以及托管堆内有多少数量的对象 1.1  查看有没有存在有占用大量内存的对象 <比如有某类下面的一个集合>  1.2  0 1 2各代的size<查看各代的内存是否有异常> 2.调查是否有内存泄露(重点) 2.1  查

前段时间线上服务经常发生卡顿,经过排查发现是大对象引起的Fullgc问题,特此记录排查逻辑. 目录 目的 一.获得服务进程 二.生成dump文件 三.下载mat工具 四.使用mat工具导入第二步生成的dump文件 五.导入后得到如下界面 六.定位大对象(方法一) 七.定位大对象(方法二) 目的 定位产生大对象的代码 一.获得服务进程 jps -l 27885\32474 对应的即为运行的Jar ps:也可使用netstat -lnput|grep 启动端口号 等方式查找 二.生成dump文件 j

不少人都在找FFmpeg中是否有hls(m3u8)解析的源码,其实是有的.就是ffmpeg/libavformat/hlsproto.c,它依赖的文件也在那个目录中. 如果要是单纯想解析HLS的话,建议参考https://github.com/winlinvip/srs-bench,这是一个http.hls.rtmp集合在一起的压测工具,里面的代码更专一,代码量也不大. 下面是ffmpeg/libavformat/hlsproto.c /* * Apple HTTP Live Streaming

go build 和 go install 都需要使用源码来进行编译.但是有时候我们只有.a或者.so文件.并不能获取到第三方库的源码,这时我们需要静态链接库编译的技巧: 上图是实验前的文件分布. 使用静态链接库编译命令: ➜ src go tool compile -I ../pkg/darwin_amd64/ callyx.go ➜ src go tool link -o call2 -L ../pkg/darwin_amd64/ callyx.o 实验后文件分布: 由图中我们可以看到,可执

原文地址:http://blog.csdn.net/starlee/article/details/6649605 在我上篇文章<让程序在崩溃时体面的退出之SEH>中讲解了SEH中try/except可以捕捉异常,避免程序的崩溃,并且可以在处理完异常之后,还能决定进该进程如何执行.对于应用程序的使用者来说,并不知道异常的发生.但是对于软件的开发者来说,虽然避免了程序的崩溃,可是这样可以让程序崩溃的缺陷存在于代码中,就像一个定时炸弹,不知道什么时候会爆炸.要想修复这样的缺陷,首先要找到导致程序崩

WinDbg OllyDbg SoftICE (已经停止更新) 虽说WinDbg在无源码调试方面确实比较困难,但在调试内核方面却真的有独到之处. https://www.pediy.com/kssd/pediy10/94457.html 使用Windbg解析dump文件 1 常用的Windbg指令 ①!analyze -v ②kP 可以看函数的入参 ③!for_each_frame dv /t 可以看函数中的局部变量 ④dc , db 产看某一内存中的值 可以直接接变量名 不过可能需要回溯栈 ⑤

突然有一天部署在服务器的一个应用挂掉了,没办法只能进入服务器打开 [事件查看器]查看下,好不容易找到了打开后一脸懵逼 事件查看器查到的内容根本对我们排障没有任何作用. 在这个时候如果有对应的dump文件就能派上用场了, 只要有dump文件就能查到应用挂掉那刻的一手情报,可能有人认为分析dump文件是非常难的事情, 但是最近不断有新的dump分析工具出来,例如用vs2017就能够很简单的分析dump文件. 接下来我们用几个实际的例子来看看如何用vs2017来分析dump文件吧 dump文件的收集

1.简介 在上一篇文章中,我详细分析了 MyBatis 配置文件的解析过程.由于上一篇文章的篇幅比较大,加之映射文件解析过程也比较复杂的原因.所以我将映射文件解析过程的分析内容从上一篇文章中抽取出来,独立成文,于是就有了本篇文章.在本篇文章中,我将分析映射文件中出现的一些及节点,比如 <cache>,<cache-ref>,<resultMap>, <select | insert | update | delete> 等.除了分析常规的 XML 解析过程外

1.首先,java程序启动在linux,怎么生成dump文件? 1>第一步,首先你需要得到java程序的PID,最简单的方法使用如下命令 ps -ef|grep java 或者如果是docker启动的  springboot服务,也可以使用本命令: 2>在任意位置,执行jmap命令,生成dump文件 jmap -dump:format=b,file=serviceDump.dat jmap -dump:format=b,file=serviceDump.dat [java进程的PID] 可以看

使用C++开发系统有时会出现段错误,即Segment Fault.此类错误程序直接崩溃,通常没有任何有用信息输出,很难定位bug,因而无从解决问题.今天我们介绍core dump文件,并使用gdb进行调试,以此来定位段错误问题.此文同时用以备忘. 一.core dump Core dump也称核心转储, 当程序运行过程中异常退出时, 由操作系统把程序当前的内存状况存储在一个core文件中, 称之为core dump文件. 系统默认不生成core dump文件,可以使用ulimit命令进行查看和设

Mybatis源码分析: 1.配置文件解析: 1.1源码阅读入口: org.apache.ibatis.builder.xml.XMLConfigBuilder.parse(); 功能:解析全局配置文件,调用parse.evalNode()方法,将指定路径的config配置文件转换为XNode对象,然后调用parseConfiguration()方法逐步解析配置文件中的各个节点: 1.2 mapperElement():解析mappers标签,解析过程中就是对映射文件的解析过程 2. Mappe

1 Jprofile简介 官网 下载对应的系统版本即可 性能查看工具JProfiler,可用于查看java执行效率,查看线程状态,查看内存占用与内存对象,还可以分析dump日志. 2 功能简介 选择attach to a locally running jvm 选择需要查看运行的jvm,双击或者点击start 等待进度完成,弹出模式选择 Instrumentation模式记录所有的信息.包括方法执行次数等Sampling模式则只支持部分功能,不纪录方法调用次数等,并且更为安全 由于纪录信息很多,

那些不靠谱的工具 先来说说那些不靠谱的工具,就是今天吭了我小半天的各种工具,看官上坐,待我细细道来.IDA pro IDA pro6.6之后加入了dex动态调试功能,一时间普天同庆.喜大普奔.兴奋之后你才会发现IDA这东西在动态调试方面真的是很挫,就算他是静态反编译之王,我也不得不说他的动态调试功能还非常需要加强.先说说使用ida调试dex的方法. IDA pro调试dex流程: 1.  用apktool反编译apk,添加android:debuggable="true",重打包apk

doctotext中没有make install选项,make后生成可执行文件 在buile目录下面有.so动态库和头文件,需要的可以从这里面拷贝 build/doctotext就是可执行程序.   doctotext内置了两种检测文件类型方法: 1.以后缀为依据检测文件类型 2.以内容为依据检测文件类型   下面是doctotext支持的文件类型: DOC, XLS, XLSB, PPT, RTF, ODF (ODT, ODS, ODP), OOXML (DOCX, XLSX, PPTX),

版权声明:本文为博主原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接和本声明. 本文链接:https://blog.csdn.net/lk142500/article/details/80563552 1 简介 第一次遇到程序崩溃的问题,之前为单位开发了一个插件程序,在本机运行没有出现问题,但把生成的可执行文件拷贝到服务器上一运行程序,刚进入插件代码,插件服务就崩溃了,当时被这个问题整的很惨,在同事的帮助下了解到,对于程序崩溃,最快的解决方式是生成dump文件,通过生成du

我们已经了解了什么是Dump文件,它保存了什么数据,有什么作用,但它是如何存储的,数据格式是怎样的呢.下面简单说一下. 一.总体结构 二.文件头 首先文件的最开始的32个字节是Dump文件的文件头,这里包含了Dump文件标识.格式版本.校验和.时间戳和一些标志,数据结构如下 typedef struct _MINIDUMP_HEADER { ULONG32 Signature; ULONG32 Version; ULONG32 NumberOfStreams; RVA StreamDirecto

转载[文尾出处链接] 1 简介第一次遇到程序崩溃的问题,之前为单位开发了一个插件程序,在本机运行没有出现问题,但把生成的可执行文件拷贝到服务器上一运行程序,刚进入插件代码,插件服务就崩溃了,当时被这个问题整的很惨,在同事的帮助下了解到,对于程序崩溃,最快的解决方式是生成dump文件,通过生成dump文件使用调试工具进行调试,还原程序崩溃时的状态,能够起到快速定位排查问题的作用.Dump文件是进程的内存镜像.可以把程序的执行状态通过调试器保存到dump文件中.Dump文件是用来给驱动程序编写人员调

前言 在windows 下 系统核心态程序蓝屏,会产生dump文件. 用户级程序在设置后,程序崩溃也会产生dump文件.以方便开发者用windbg进行分析. so,linux 系统也有一套这样的东东----->Linux Core Dump Linux Core Dump 引用 文章 <Linux Core Dump>  http://www.cnblogs.com/hazir/p/linxu_core_dump.html 的话: 当程序运行的过程中异常终止或崩溃,操作系统会将程序当时的

前言 在产品的实际应用环境中,如果我们的程序在客户那里出现了问题,例如程序异常了,而这个时候的现象又不能还原或者很难还原重现,那么只有使用dump文件来保存程序的当前运行信息,例如调用堆栈等,同时使用符号文件来定位问题了;这里主要讲解使用dbghelp库来生成输出dump文件,同时使用符号文件和windbg来分析问题.样例代码 1 #include "stdafx.h" 2 #include <Windows.h> 3 #include <iostream> 4