dump文件

生成hprof文件 ①，top出异常进程 ②，生成异常进程的dump文件 jmap -dump:format=b,file=[文件名] [进程] jmap -dump:format=b,file=heap.hprof 2576 ③，使用JProfiler分析hprof 文件 使用JProfiler分析大对象 ①，导入：session->open snapshot ②，查看大对象：Heap Walker -> Current Object Set ->Giggest Object 来源： https://www.cnblogs.com/wanhua-wu/p/11684716.html

客户提出导入报错 一、报错如下 SYMPTOMS DataPump Import (IMPDP) fails with the following errors: ORA-39002: invalid operation ORA-31694: master table "<master table name>" failed to load/unload ORA-31640: unable to open dump file "<dump file name>" for read ORA-19505: failed to identify file "<dump file name>" ORA-27046: file size is not a multiple of logical block size 二、匹配MOS DataPump Import (IMPDP) Fails With Errors ORA-39002 ORA-31694 ORA-31640 ORA-19505 ORA-27046 (文档 ID 785473.1) 重新导出导入，dump文件损坏 来源： https://www.cnblogs.com/lvcha001/p/11676380.html

目录 生成Java core dump core dump分析 生成Java core dump 可以按照下面这个文章的指引来通过jni调用触发Java core dump Generating a Java Core Dump 基本思路是通过Java调用本地C代码，然后在C代码中触发一个错误，从而引发jvm crash。 需要注意两个问题 gcc编译的时候需要注意库的名称，例子里面是 libnativelib.so ，需要改为 libnativelib.jnilib $ gcc -fPIC -o libnativelib.jnilib -shared \ -I$JAVA_HOME/include/linux/ \ -I$JAVA_HOME/include/ \ CoreDumper.c 例子中的命令是基于linux的，如果在mac下jni_md.h头文件的位置和linux稍有不同，在用gcc编译的时候要注意下，需要把jni_md.h文件复制到对应的目录 sudo cp $JAVA_HOME/Contents/Home/include/darwin/jni_md.h $JAVA_HOME/Contents/Home/include java.lang.UnsatisfiedLinkError: no XXX in java.library.path 在执行java

按照Linux系统的设计哲学，内核只提供dump内存的机制，用户想要dump什么样的内存，dump多少内存是属于策略问题，由用户来决定。 在真实的使用场景中，主要有两种使用方式：kdump和coredump 1.kdump：dump某一个进程的地址空间来供用户在进程挂掉之后debug分析。 2.coredump：dump整个系统的内存空间，以便于系统管理员debug分析系统挂掉的原因。 本文主要描述kdump kdump整个过程依赖kexec和一个额外的dump内核来保证整个流程正确的执行。 kdump涉及的组件： 1.kdump专用内核，通过kexec工具load到预留的内存中，供故障引导使用。 2.kexec工具，负责加载crash内核，以及一些启动参数传递。 3.makedumpfile工具，负责将故障内核的内存copy，压缩，写入指定文件。 kdump的实现 kdump整个流程涉及到两次内核启动： 1.首先是工作内核启动，包括硬件自检初始化，BootLoader加载内核并发引导内核启动，然后配置预留内存，并使用kexec工具将crash内核加载到保留内存中。 2.工作内核在遇到故障触发panic之后启动crash kernel，kexec启动crash kernel只执行内核初始化逻辑，不再做硬件自检初始化，启动速度很快。 3

使用WinDbg调试程序 WinDbg是微软发布的一款相当优秀的源码级(source-level)调试工具，可以用于Kernel模式调试和用户模式调试，还可以调试Dump文件。 WinDbg是微软很重要的诊断调试工具: 可以查看源代码、设置断点、查看变量, 查看调用堆栈及内存情况。  调试应用程序(用户模式 user mode)  调试操作系统及驱劢程序(内核模式 kernel mode)  调试非托管程序(native program)  调试托管程序(managed program)  实时调试 (JIT: Just in time)  事后调试 (postmortem debugging) 使用WinDbg可以解决线上.NET应用程序的如下问题： ◆ 内存高 ◆ CPU高 ◆ 程序异常 ◆ 程序Hang死 在生产环境下进行故障诊断时，为了不终止正在运行的服务或应用程序，有两种方式可以对正在运行的服务或应用程序的进程进行分析和调试。 一、用WinDbg等调试器直接attach到需要调试的进程，调试完毕之后再detach即可。但是这种方式有个缺点就是执行debugger命令时必须先break这个进程，执行完debug命令之后又得赶紧F5让他继续运 行，因为被你break住的时候意味着整个进程也已经被你挂起。另外也经常会由于First Chance

一、打包命令 　　格式： tar 参数 新建的文件名 filename 　　　　参数： -c 新建打包文件，可搭配-v 来查看过程中被打包的文件名 　　　　　　　-x 解打包或解压缩的功能。 　　　　　　　-z 通过bzip2的支持进行压缩/解压缩，此时文件名最好是 .tar.gz 　　　　　　　-f filename -f 后面要接被处理的文件名， 　　　　　　 -c 目录，这个参数用在解压缩时， 　　　　　　 -v 在压缩或解压缩的过程中，将正在处理的文件名显示出来 　　　　其实最简单的使用tar 就只要记住下面的方式： 　　　　　　压缩： tar -cvfz filename.tar.gz 要被压缩的文件或者目录 　　　　　　解压缩: tar -xvfz filename.tar 二、完整备份工具: dump 　　　dump 参数 待备份数据 　　　　参数： -S 仅列出后面的待备份的数据需要多少磁盘空间才能备份完毕。 　　　　　　　-u 将这次dump的时间记录到 /etc/dumpdateS 文件中 　　　　　　 -v 将dump的文件过程显示出来 　　　　　　　-level 就是我们谈到的等级，从-0 到-9 共10个等级 　　　　　　　-f 有点类是tar 后面接产生的文件 　　　　　　 -w 列出在，/etc/fstab 里面的具有dump 是指的分区是否有备份过。

dump和load是对于json格式的写入和读取，dumps和loads只是类型转换 dump ： 　　是将dict(字典格式)转换为str(字符串格式)，并且写入到json文件中 　　例如： 　　　　 dumps： 　　是将dict(字典格式)转换为str(字符串格式)。 　　例如： 　　　　 　　运行结果： 　　　　 load： 　　用于从json文件中读取数据 　　例如： 　　　　 　　运行结果： 　　　　 loads： 　　用于将str(字符串类型)转换为dict(字典类型) 　　例如： 　　　　 　　运行结果： 　　　　 来源： https://www.cnblogs.com/ifiwant/p/11382085.html

title author date CreateTime categories win10 uwp 收集 DUMP 文件 lindexi 2019-09-03 17:48:44 +0800 2018-11-15 08:41:45 +0800 Win10 UWP 如果在用户端软件直接退出，在以前 win32 程序可以使用 DUMP 进行调试。在 UWP 需要在电脑的注册表做一些配置才可以收集到 DUMP 文件 打开注册表，通过 win+R 运行 regedit 就可以打开注册表 注册表可以输入路径，请输入 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting 请看下面 如果不存在 LocalDumps 文件夹，请右击创建一个 右击新建项，输入 LocalDumps 保存 右击新建一个可扩展字符串，写入 DumpFolder 然后双击输入 DUMP 文件可以存放的文件夹，注意这个文件夹需要有权限 接着右击新建 DWORD 32 位，输入 DumpCount 再双击输入值，这个表示最多可以存放多少个 DUMP 文件，默认值是 10 个 右击新建 DWORD 32 位，输入 DumpType 再双击输入值，设置存放的 DUMP 是什么 DUMP 可以选的值有三个。输入 0 是 Custom dump

转自： https://www.cnblogs.com/Anker/p/6079580.html 1、前言 　　一直在从事linux下后台开发，经常与core文件打交道。还记得刚开始从事linux下开发时，程序突然崩溃了，也没有任何日志。我不知所措，同事叫我看看core，我却问什么是core，怎么看。同事鄙视的眼神，我依然在目。后来学会了从core文件中分析原因，通过gdb看出程序挂再哪里，分析前后的变量，找出问题的原因。当时就觉得很神奇，core文件是怎么产生的呢？难道系统会自动产生，可是我在自己的linux系统上面写个非法程序测试，并没有产生core问题？这又是怎么回事呢？今天在ngnix的源码时候，发现可以在程序中设置core dump，又是怎么回事呢？在公司发现生成的core文件都带有进程名称、进程ID、和时间，这又是怎么做到的呢？今天带着这些疑问来说说core文件是如何生成，如何配置。 2、基本概念 　　 当程序运行的过程中异常终止或崩溃，操作系统会将程序当时的内存状态记录下来，保存在一个文件中，这种行为就叫做Core Dump（中文有的翻译成“核心转储”)。我们可以认为 core dump 是“内存快照”，但实际上，除了内存信息之外，还有些关键的程序运行状态也会同时 dump 下来，例如寄存器信息（包括程序指针、栈指针等）、内存管理信息、其他处理器和操作系统状态和信息

一、coredump：是针对程序异常而产生的core文件，包含程序运行时的内存、寄存器状态、堆栈指针、函数调用等信息，用于存储程序出错时的状态。 二、coredump的存储位置：与被执行文件在同一目录下。当然，位置可以在程序中通过 chdir 命令修改 三、如何判断是coredump文件：该文件主要的格式为 ELF 格式。可以通过 readelf -h core 进行判断，如图： 四、产生coredump的条件： 首先确认 当前会话 中的ulimit -c，若为0，则不会产生core，需要修改和设置。 附： ulimit -c unlimited #可以产生core且不受大小限制 ulimit -a #显示当前各种用户进程设置 #ulimit的某些参数设置与运行机器的配置有关，慎重使用。 ulimit -d unlimited #数据段长度 ulimit -m unlimited #最大内存大小 ulimit -s unlimited #堆栈大小 #以上是设置为无限制 #若是想设置对应字符大小，可以指定如下图： ulimit -c [size] 可能 -c 设置成 4 也不会生成core，因人而异。 当前用户对写入core目录的写权限有足够的空间。 其他不会产生core文件的原因。 五、coredump产生的几种情况 内存访问越界 多线程程序使用不安全的线程函数