dump文件

作者：lds( lds2012@gmail.com ) 日期：2017-03-24 一. BreakPad简介 Google breakpad是一个跨平台的崩溃转储和分析框架和工具集合。 Breakpad由三个主要组件： client，以library的形式内置在你的应用中，当崩溃发生时写 minidump文件 symbol dumper, 读取由编译器生成的调试信息（debugging information），并生成 symbol file processor， 读取 minidump文件 和 symbol file ，生成可读的c/c++ Stack trace. 简单来说就是一个生成 minidump，一个生成symbol file，然后将其合并处理成可读的Stack trace。 二. MiniDump文件格式 minidump文件格式是由微软开发的用于崩溃上传，它包括： 当dump生成时进程中一系列executable和shared libraries, 包括这些文件的文件名和版本号。 进程中的线程列表，对于每个线程，minidump包含它在寄存器中的状态，线程的stack memory内容。这些数据都是未解析的字节流，Breakpad client通常没有调试信息（debugging information）能生成函数名，行号，甚至无法确定stack frame的边界

　　也不知道曾几何时，Windows就为了调试应用程序崩溃、蓝屏等错误加了很多log和dump。所谓dump，就是将内存里的部分或全部数据写到文件中，以便开发者、程序员查看和调试，发现问题所在。比如在系统属性里，高级——启动和故障恢复——写入调试信息，一般用户版本的Windows（Win2000 Pro, WinXP）都是小内存转储（Small memory dump, 64K），而服务器版本的Windows默认是完全内存转储。又比如Drwatson（华生医生，在附件——系统工具——系统信息，工具菜单中可以找到），默认是应用程序崩溃后创建崩溃的dump文件，一般在C:\Documents and Settings\Administrator\Local Settings\Application Data\Microsoft\Dr Watson\目录下会有user.dmp文件，如果不删除，会占用越来越大的空间。当然可以通过配置drwatson，让它不产生dump文件。其实普通用户根本用不着这些转储文件，最多看看log就行了。而过多的dump文件除了占用硬盘空间，一点用处都没有。 　　但现在又多了个PCHealth（好像从WinME开始就有的？），似乎也是用来记录系统运行情况的，但没有对外可以配置的界面（？），而且它会不声不响地在应用程序崩溃时也进行dump，在C:\WINDOWS

1 lib配置 项目-->属性-->配置属性-->链接器-->输入-->附加依赖项 增加dbghelp.lib 2 头文件 #include <imagehlp.h> #include <Windows.h> 3 main函数 在第一行调用window api：SetUnhandledExceptionFilter(UnhandledExceptionFilter2); 4 UnhandledExceptionFilter2的实现 LONG WINAPI UnhandledExceptionFilter2(struct _EXCEPTION_POINTERS* ExceptionInfo) { string strDumpFile = "exception.dmp "; HANDLE hFile = CreateFile(strDumpFile.c_str(), GENERIC_WRITE, FILE_SHARE_WRITE, NULL, CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL, NULL ); if (hFile!=INVALID_HANDLE_VALUE) { MINIDUMP_EXCEPTION_INFORMATION ExInfo; ExInfo.ThreadId = ::GetCurrentThreadId(); ExInfo

public class OOM { private static List<Byte[]> list = new ArrayList<Byte[]>(); public static void main(String[] args) { Zip zip = new Zip(); zip.test(list); } } public class Zip { private List<Byte[]> a = null; public List<Byte[]> getA() { return a; } public void setA(List<Byte[]> a) { this.a = a; } public void test(List<Byte[]> list){ Zip n = new Zip(); n.setA(list); R r = new R(); r.test1(n); } } public class R { public void test1(Zip z){ while(true){ Byte[] b = new Byte[100000]; z.getA().add(b); } } } 我刻意的制造了一段会溢出的代码。 通过下图的leak suspects分析是可以看出gc root的。比较代码和图中的b a。 还有其他的方式可以分析，点击dominator

前言 做软件开发的同学会花费大约1/3的时间来进行调试，一个软件开发人员的技能包括:coding,调试和设计.一个友好的开发环境中必然提供了相当多的调试工具给开发人员，例如linux环境下C/C++有基于信号的core dump文件，java、python等都有自己的dump机制，而kdump就是为内核开发而生的dump机制，是 kernel dump 的缩写。而kdump比较重，对于内存较大的服务器耗时较长，所以简单的问题可以简单抓取崩溃时的dmesg就可以了，可以利用pstore，例如x86上的 ramoops ,嵌入式上的 mtdoops ，是比较轻量的方式。但是这些轻量工具对于解决某些复杂问题上不够给力，仍然需要kdump来抓取内存数据并分析。 dump主要用来做什么 dump主要是抓取程序在内存中的数据，你可以使用gdb直接attach某个程序并且 dump memory file start_addr end_addr ，dump做的事情就是这样，将内存中的数据抓取出来。但是每个应用的用户空间太大了，不可能都抓取出来，一般只需要根据 /proc/xxx/maps 的地址段dump就好，所以这么多dump数据还需要有格式，而在linux上elf大行其道，我们通常的core dump是elf的，他会为每个 /proc/xxx/maps 中的每个段都生成一个program

生成dump文件的命令： jmap -dump:format=b,file=20170307.dump 16048 file后面的是自定义的文件名，最后的数字是进程的pid 使用jvisualvm来分析dump文件： jvisualvm是JDK自带的Java性能分析工具，在JDK的bin目录下，文件名就叫jvisualvm.exe。 jvisualvm可以监控本地、远程的java进程，实时查看进程的cpu、堆、线程等参数，对java进程生成dump文件，并对dump文件进行分析。 像我这种从服务器上dump下来文件也可以直接扔给jvisualvm来分析。 使用方式：直接双击打开jvisualvm.exe，点击文件->装入，在文件类型那一栏选择堆，选择要分析的dump文件，打开。 来源： CSDN 作者： 那些年的代码 链接： https://blog.csdn.net/weixin_44018338/article/details/103618892

请看示例（图1）： 很明显，在代码行108行有一个对空指针p的赋值操作，在IDE环境下运行，结果如下（图2）： 提示p是nullptr。一位曾经工作于中科院的学者告诉我，程序运行过程中出现错误提示，90%都是错误指针（空指针、野指针）引起的，鉴于多年工作经验的总结，对于这一点我深信无疑。IDE环境下运行，我们很容易发现和解决类似这种错误，但是如果我们脱离IDE运行，一般都会提示0xC0000005错误提示对话框，这个时候要解决这种问题就有些茫然了，手足无措，不知如何下手了。要解决类似这种问题，我们需要借助应用程序异常调试信息记录文件CrashDump文件，那么我们如何来生成这样的文件呢？请看修改后的代码： void ExpTest5() { char *p = NULL; p[0] = 0; } void ExpTest4() { ExpTest5(); } void ExpTest3() { ExpTest4(); } void ExpTest2() { ExpTest3(); } void ExpTest1() { ExpTest2(); } #include <dbgHelp.h> #pragma comment(lib, "dbghelp.lib") void WINAPI WriteCrashDumpFile(_EXCEPTION_POINTERS * pExInfo,

TfLite micro中打印model 结构的方法 在tflite for micro中，提交了micro_optional_debug_tools.h/cc等文件用于得到类似如下的打印： 打印出的信息 Interpreter has 16 tensors and 7 nodes Inputs: 1 Outputs: 0 Tensor 0 Identity kTfLiteFloat32 kTfLiteArenaRw 16 bytes ( 0.0 MB) 1 4 Tensor 1 conv2d_10_input kTfLiteFloat32 kTfLiteArenaRw 1536 bytes ( 0.0 MB) 1 128 3 1 Tensor 2 sequential_5/conv2d_10/Conv2D/ReadVariableOp kTfLiteFloat32 kTfLiteMmapRo 384 bytes ( 0.0 MB) 1 4 3 8 Tensor 3 sequential_5/conv2d_10/Conv2D_bias kTfLiteFloat32 kTfLiteMmapRo 32 bytes ( 0.0 MB) 8 Tensor 4 sequential_5/conv2d_10/Relu kTfLiteFloat32 kTfLiteArenaRw 12288

Java 内存诊断比较容易， 需要： 1 获取heap dump 2 分析heap dump 1.1 获取dump之1 VM arguments: -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./java_pid<pid>.hprof reference for VM options: http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html 如果不指定， dump文件默认输出到user.dir中, 可用jinfo <pid>获取user.dir变量设置。 java.lang.OutOfMemoryError: Java heap space Dumping heap to java_pid8096.hprof ... Heap dump file created [168062394 bytes in 1.306 secs] 注意得到文件后，可用下面命令进行分析： jmap -histo ./java_pid<pid>.hprof 1.2 获取dump之2 jmap/jcmd jmap -dump:format=b,file=snapshot.jmap <pid> jcmd <process id/main class> GC

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一、运行时错误 任何人写程序都会出错，正如《C++编程规范》所说，真正可怕的错误不是编译时的错误，而是运行时错误。 有的程序可以通过编译， 但在运行时会出现Segment fault(段错误) 这通常都是指针错误（一般就是空指针）引起的，或者访问了不能访问的内存（数组越界，系统保护） 二、core文件 我们不可能用GDB一句一句的去找，真正的英雄都善于使用手中的武器。这就是core file 所谓core，就是当程序down掉的时候，操作系统把程序的内存内容dump下来，这个动作就是core dump，动作的结果就是core文件 产生： 1.程序挂了，操作系统产生 2.通过gcore $pid命令直接导出相应进程的core文件，此命令运行后， 会恢复程序的执行， 不影响程序的运行 3.通过另一个进程发送SIGABRT信号给当前进程， 虽然也能产生core文件，但是程序随着一起终止掉 三、core文件开关设置 1.终端级别 怎么样才能让程序down掉的时候，自动core dump呢？可以通过 ulimit查看和设置 #查看core文件的信息 ulimit -a ju@musicoder:~$ ulimit -a core file size (blocks， -c) 0 data seg size (kbytes