dump文件

SQL> select * from city; ID NAME ---------- ---------- 7 Chicago 6 JerseyCity 8 Manhattan 1 New York 3 Dallas 4 Beijing 5 Shanghai 2 Washington 8 rows selected. SQL> select file_id,block_id,blocks FROM DBA_EXTENTS where segment_name='CITY'; FILE_ID BLOCK_ID BLOCKS ---------- ---------- ---------- 6 288 8 select id,dbms_rowid.rowid_object(rowid) object_id,dbms_rowid.rowid_relative_fno(rowid) file_id,dbms_rowid.rowid_block_number(rowid) block_id,dbms_rowid.rowid_row_number(rowid) num,rownum from swat.city; ID OBJECT_ID FILE_ID BLOCK_ID NUM ROWNUM ---------- ---------- ---------- ---------- -----

2010-02-13 目的： 1、 了解数据块转储 2、 简单认证数据在ORACLE文件的存储 测试环境： VM+Win2003+Oracle11g DB_BLOCK_SIZE 8k C:\Documents and Settings\Administrator>sqlplus /nolog SQL*Plus: Release 11.2.0.1.0 Production on 星期一 2月 13 21:03:38 2012 Copyright (c) 1982, 2010, Oracle. All rights reserved. SQL> conn / as sysdba 已连接。 SQL> create tablespace test1 datafile 'E:\app\Data\orcl\test1' size 20M ; 表空间已创建。 SQL> Create user firefox identified by qwe123 temporary tablespace temp default tablespace test1 quota unlimited on test1; 用户已创建。 SQL> select extent_management,allocation_type,segment_space_management from dba_tablespaces

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

core 文件的简单介绍 当程序运行的过程中异常终止或崩溃，操作系统会将程序当时的内存状态记录下来，保存在一个文件中，这种行为就叫做Core Dump（中文有的翻译成“核心转储”)。我们可以认为 core dump 是“内存快照”，但实际上，除了内存信息之外，还有些关键的程序运行状态也会同时 dump 下来，例如寄存器信息（包括程序指针、栈指针等）、内存管理信息、其他处理器和操作系统状态和信息。core dump 对于编程人员诊断和调试程序是非常有帮助的，因为对于有些程序错误是很难重现的，例如指针异常，而 core dump 文件可以再现程序出错时的情景。 关闭系统生成 core 文件 : ulimit -c 0 检查生成 core 文件的选项是否打开 : ulimit -a 该命令将显示所有的用户定制，其中选项 -a 代表“ all ”。 系统文件调整 core 选项： /etc/profile # No core files by default ulimit -S -c 0 > /dev/null 2>&1 用户自定义调整 core 选项： 在用户的 ~/.bash_profile 里加上 ulimit -c unlimited 来让特定的用户可以产生 core 文件。 在终端中输入ulimit -c 如果结果为0，说明当程序崩溃时，系统并不能生成core dump。

一、常见故障介绍　　 　　最近在开发相机项目（项目细节由于公司保密就不介绍了），程序运行5个来月以来首次出现msvcr100.dll故障等问题，于是乎开始了分析之路，按照度娘上的一顿操作，期间也是出现了各种不一样的问题，现总结了遇到的问题如： 1、MSVCR100.dll/MSVCR100D.dll/MSVCP100.dll/MSVCP100D.dll问题 　　问题事件名称: APPCRASH 　　故障模块名称: MSVCR100.dll 2、R6010错误 　　现场遇到的情况基本都是这两类 二、故障排查 1、静心思考 　　主要说一下我走过的历程，心酸只有自己知道，排查问题难免浮躁，但一定要沉得住，浮躁主要有以下几点： 程序明明在自己机器上运行的好好的在客户机器上就会出问题； 程序明明试着好好的，可你一离开就出现问题； 程序连续运行好几个月版本都稳定了，可突然出问题，换电脑又复现不出来； 连续处理一段时间后仍然没有结果，客户领导天天催。 2、检查库 1、如果新打包的程序提示缺少MSVCR100.dll、MSVCP100.dll”或者“MSVCR100d.dll\MSVCP100d.dll”等类似错误信息，请从源机器或者网上下载该库拷贝到目标机器，库分32位和64位（跟自己操作系统有关），32拷贝到C:\Windows\System32，64位拷贝到C:\Windows

Kdump 是一种的新的crash dump捕获机制，用来捕获kernel crash时候产生的crash dump。Kdump需要配置两个不同目的的kernel，其中一个我们在这里称作standard(production) kernel；另外一个称之为Crash(capture)kernel。 standard（production）kernel，是指我正在使用的kernel，当standard kernel在使用的过程中出现crash的时候， kdump会切换到crash kernel, 简单来说，standard kernel会正运行时发生crash，而crash(capture) Kernel 会被用来捕获production kernel crash时候产生的crash dump。 捕获crash dump是在新的crash(capture) kernel 的上下文中来捕获的，而不是在standard kernel上下文进行。 具体是当standard kernel方式crash的时候，kdump通过kexec（后面介绍）自动启动进入到crash kernel当中。如果启动了kdump服务，standard kernel会预留一部分内存， 这部分内存用来启动crash kernel。 kdump机制主要包括两个组件：kdump和kexec kexec

一、说明 在前一家公司经常测出一些缓冲区溢出导致进程挂掉的问题，开发经常要求在调试模式进行测试，生成core文件给他们定位问题。 当时的调试模式启动只是修改某些配置文件重新启动即可，所以在很长一段时间内并不知道到底要如何生成core文件及core文件如何使用。 二、配置允许生成core文件 临时配置使用ulimit命令进行操作即可： # 查看当前用户core文件配置情况 # 0表示允许core文件大小为0，亦即不允许生成 ulimit -c # 限制core文件大小 # 禁止生成core文件 ulmit -c 0 # 限制core文件大小100块 ulimit -c 100 # 不限制core文件大小 ulimit -c unlimited 要永久生效则修改配置文件/etc/security/limits.conf，使用类似如下形式进行配置： * soft core unlimited 三、直接的core文件生成 3.1 通过kill触发生成 # 查看当前core文件大小限制 ulimit -c # 设置成不限制大小 ulimit -c unlimited # 再次查看core文件大小限制 ulimit -c # 新启动一个bash进程 bash # 查看当前bash的pid echo $$ # 将该进程kill掉，触发core文件生成 kill -s SIGSEGV $$ #

DUMP数据的原理 常见的Dump的软件有LoadPE、PETools等，这类工具在进行Dump数据的时候采用的主要的方式是利用Moudle32Next来获取将要Dump的进程的基本信息。Moudle32Next的原型如下： BOOL Moudle32Next ( HANDLE hSnapshot , LPMODULEENTRY32 lpme ) /*参数具体如下： hSnapshot:之前调用的CreateToolhelp32Snapshot函数返回的快照 lpme 指向MODULEENTRY32结构的指针*/ MODULEENTRY32结构的定义如下： typedef struct tagMODULEENTRY32 { DWORD dwSize ; DWORD th32ModuleID ; DWORD th32ProcessID ; DWORD GlblcntUsage ; DWORD ProccntUsage ; BYTE * modBaseAddr ; DWORD modBaseSize ; HMODULE hModule ; char szModule [ MAX_MODULE_NAME32 + 1 ] ; char szExePath [ MAX_PATH ] ; } MODULEENTRY32 ;

;0 原样输出xdebug 1 启动xdebug的var_dump() 2 除了会启动xdebug的var_dump之外还会在浏览器显示当前文件路径 xdebug.overload_var_dump = 1 ;以下三选项是个配置xdebug输出完整变量内容 包括数组 字符串 ;整数类型,默认值128,用于控制通过xdebug var_dump(),var_dump()方法时显示数组中子数组的个数或对象中属性的个数,设定为-1关闭该限制 xdebug.var_display_max_children=-1 ;整数类型,默认值521,用于控制xdebug var_dump(),var_dump()方法时显示输出的字符串的长度,设定为-1关闭该限制。 xdebug.var_display_max_data=-1 ;整数类型，默认值3。用于控制通过xdebug var_dump(),var_dump()方法时打印数组或对象时显示的层数,即深度,可设定的最大值为1023,也可以将其设定为-1以达到设定最大值的效果 xdebug.var_display_max_depth=-1 来源： CSDN 作者： weixin_45765705 链接： https://blog.csdn.net/weixin_45765705/article/details/103271043

前言 我们在发布了自己的App以后，Windows Phone的Error Report机制会帮助我们收集程序的崩溃信息并发送到微软的服务器上，这可以辅助开发者提高App的稳定性。 那么如何利用这些dump file呢？首先我们需要下载这些dump file从微软开发者网站，然后借助调试工具进行分析，我们这里选用Windbg。 下载步骤 1. 登录 http://dev.windows.com/en-us/dashboard 2. 选择Windows Phone Store 3. 进入Reports，选择Crash count，选择 App和日期，点积Refresh按钮 4. 点击导出stack traces，这里包括最近30天的崩溃转存记录 5. 开发下载后的Excel文件，这个excel文件里面包含9列。分别是App的名字，App的ID，App的版本号，操作系统的版本号，出现问题的函数，异常类型，在30天内累计的崩溃次数，栈的回溯和Dump File下载地址。 6. 我们可以通过第E和F列快速看一下，是否是由我们的App导致的崩溃，然后点击下载dump file进行分析。 使用Windbg打开dump file 1. 下载windbg从微软的网站: http://msdn.microsoft.com/en-us/library/windows/hardware/ff551063