调试Release程序--Dump文件方式

合集下载

Release版程序调试技巧

Release版程序调试技巧

Release版程序调试技巧环境及工具:windows 9x/2000/xp,VC 6.0(SP6)Win32Dasm 8.93CrashFinder在软件产品的测试过程中,以及发布之后,程序可能会由于一般保护错(GPF)而崩溃。

即程序中访问了禁止访问的内存。

这时,程序一般情况下无法继续运行,只能结束。

在安装了调试器(比如VC)的系统中,会弹出一个错误对话框,显示类似:“0x12345678”指令引用的”0x000000123”内存。

该内存不能为”written(read)”终止单击确定,调试单击取消。

没有调试器的系统中一般会出现一个Dr. watson窗口,内容类似。

通常,我们遇到这个问题时只能大致地从程序运行(上下文)情况来粗略推断错误,但实际上有更好的解决办法。

在开发过程中,编译release版本的程序(包括EXE、DLL、OCX等二进制程序)时,要建立相关的mapfile,即映像文件。

方法如下(VC):(1)选择release版本;(2)Project settings => C/C++ => Debug Info,选“Line Number Only”;(3)Project settings => link => 选中“Generate mapfile”;(4)Project settings => link => Project Option中,输入:/mapinfo:lines这样,编译后就会生成一个*.map的文本文件,其中包含了release版本程序的相关信息。

当程序出现GPF时,记下指令地址,然后可以在map文件中的Rva+Base 段查找相关的信息。

比如:H1接口程序,出错指令为0x0040d7a0,在map文件中,可发现:0001:0000c730 ?RefreshDevList@@YGIPAX@Z 0040d730 f FFServer.obj其中0040d730是小于0040d7a0的最大地址,则可初步断定是在RefreshDevList函数中出的问题。

Windows调试工具入门2(WinDbg基本调试器设置)

Windows调试工具入门2(WinDbg基本调试器设置)

Windows调试工具入门2—基本调试器设置设置Windows调试工具入门-2本篇介绍Windows调试工具的基本设置和基本操作方法。

这里我们会用一个测试程序一步一步说明如何使用WinDbg开始调试工作。

首先用VC建立一个名为TestDebug1的控制台项目,并生成它。

、源码和可执行映像路径设置符号、一、符号使用WinDbg开始调试工作之前,最重要的就是配置好各种环境了。

这使得调试器可以正确识别调试目标中的各种变量、函数等等,使得我们能够进行符号化调试或者源码调试,而不是只能在一堆汇编代码中转圈。

首先来看一下未设置环境之前的样子。

使用刚才说的TestDebug1项目,为了对比更清晰,用Release进行编译,链接选项中选中生成map文件和调试信息,如下:在C/C++选项卡中设置如下:程序代码如下:#include "stdafx.h"#include <stdio.h>int main(int argc, char* argv[]){printf( "TestDebug1.cpp");return 0;}编译之后,将Release目录下的TestDebug1.pdb剪切到其他目录下(如果没有这样做,由于编译出来的程序中包含了符号文件路径,调试器可以直接使用exe中的信息找到pdb文件,而不需要设置路径)。

在map文件中可以看到像下面这样的内容:0001:00000000 _main 00401000 f TestDebug1.obj说明main函数位于401000地址处。

通过WinDbg的File->Open Executeable菜单打开TestDebug1.exe,可以在调试器命令窗口中看到下面的内容:可以看到,调试器自动中断下来的位置并不是程序入口点,这是由WinDbg实现造成的,这里先不管它。

调试器命令窗口中可以看到,我们还没有设置符号路径,所以WinDbg目前还找不到TestDebug1.exe的任何符号文件。

gdb调试coredump原理

gdb调试coredump原理

gdb调试coredump原理GDB调试coredump原理引言:在开发过程中,我们经常会遇到程序崩溃的情况。

为了定位程序崩溃的原因,我们需要进行调试。

而在调试过程中,有一种特殊的情况,叫做coredump。

当一个程序发生严重错误或崩溃时,操作系统会生成一个core文件,记录程序崩溃时的内存状态。

通过调试这个core文件,我们可以更加方便地找到程序的问题所在。

本文将以gdb调试coredump为主题,详细介绍其原理和使用方法。

一、什么是coredump?Coredump指的是当一个程序因为错误而异常终止时,操作系统将程序的内存状态保存到一个特殊的文件中,即core文件。

这个core文件包含了程序崩溃时的内存状态、寄存器的状态以及函数、变量的信息。

对于GDB 来说,这个core文件就是一个可调试的文件,我们可以使用GDB来调试这个文件,进一步定位程序错误的原因。

二、生成coredump文件的配置生成coredump文件的配置主要涉及到操作系统的配置和程序的编译配置。

1. 操作系统配置大多数Unix-like系统默认是开启coredump功能的,但有时会被禁用。

我们可以通过下面的命令来查看系统是否开启了coredump功能:ulimit -c如果输出为0,则表示未开启,大于0则表示开启。

我们可以通过下面的命令来开启coredump功能,并设置生成的core文件大小:ulimit -c unlimitedulimit -c <size>其中,<size>指的是core文件的大小,单位为字节。

2. 编译配置在编译程序时,我们需要添加-g选项来启用调试信息的产生。

例如,我们可以使用gcc编译C程序时,添加如下的命令行选项:gcc -g -o program program.c通过以上配置,就可以在程序崩溃时生成core文件。

三、使用GDB调试coredump文件1. 命令行方式通过命令行方式使用GDB调试coredump文件非常简单,只需指定coredump文件和可执行文件即可。

Linux crash工具

Linux crash工具

什么是 crash如前文所述,当 linux 系统内核发生崩溃的时候,可以通过 kdump 等方式收集内核崩溃之前的内存,生成一个转储文件 vmcore。

内核开发者通过分析该 vmcore 文件就可以诊断出内核崩溃的原因,从而进行操作系统的代码改进。

那么 crash 就是一个被广泛使用的内核崩溃转储文件分析工具,掌握 crash 的使用技巧,对于定位问题有着十分重要的作用。

回页首使用 crash 的先决条件由于 crash 用于调试内核崩溃的转储文件,因此使用 crash 需要依赖如下条件:1. kernel 映像文件 vmlinux 在编译的时候必须指定了 -g 参数,即带有调试信息。

2. 需要有一个内存崩溃转储文件(例如 vmcore),或者可以通过 /dev/mem 或/dev/crash 访问的实时系统内存。

如果 crash 命令行没有指定转储文件,则 crash 默认使用实时系统内存,这时需要 root 权限。

3. crash 支持的平台处理器包括:x86, x86_64, ia64, ppc64, arm, s390, s390x ( 也有部分 crash 版本支持 Alpha 和 32-bit PowerPC,但是对于这两种平台的支持不保证长期维护 )。

4. crash 支持 2.2.5-15(含)以后的 Linux 内核版本。

随着 Linux 内核的更新,crash 也在不断升级以适应新的内核。

回页首crash 安装指南要想使用 crash 调试内核转储文件,需要安装 crash 工具和内核调试信息包。

不同的发行版安装包名称略有差异,这里仅列出 RHEL 和 SLES 发行版对应的安装包名称如下:表 1. crash 工具和内核调试包系统版本crash 工具名称内核调试信息包RHEL6.2 crash kernel-debuginfo-commonkernel-debuginfoSLES11SP2 crash kernel-default-debuginfokernel-ppc64-debuginfo以 RHEL 为例,安装 crash 及内核调试信息包的步骤如下:rpm -ivh crash-5.1.8-1.el6.ppc64.rpmrpm -ivh kernel-debuginfo-common-ppc64-2.6.32-220.el6.ppc64.rpmrpm -ivh kernel-debuginfo-2.6.32-220.el6.ppc64.rpm回页首启动 crash启动参数说明使用 crash 调试转储文件,需要在命令行输入两个参数:debug kernel 和 dump file,其中 dump file 是内核转储文件的名称,debug kernel 是由内核调试信息包安装的,不同的发行版名称略有不同,以 RHEL 和 SLES 为例:RHEL6.2:/usr/lib/debug/lib/modules/2.6.32-220.el6.ppc64/vmlinuxSLES11SP2:/usr/lib/debug/boot/vmlinux-3.0.13-0.27-ppc64.debug使用 crash -h 或 man crash 可以查看 crash 支持的一系列选项,这里仅以常用的选项为例说明如下:-h:打印帮助信息-d:设置调试级别-S:使用 /boot/System.map 作为默认的映射文件-s:不显示版本、初始调试信息等,直接进入命令行-i file:启动之后自动运行 file 中的命令,再接受用户输入crash 报告分析crash 命令启动后,会产生一个转储文件的分析报告摘要,如下图所示。

debug模式和release模式区别

debug模式和release模式区别

什么是debug模式,,release模式?收藏经常有人问Debug 运行正常但Release 失败的问题。

以往的讨论往往是经验性的,并没有指出会这样的真正原因是什么,要想找出真正的原因通常要凭运气。

最近我看了一些这方面的帖子,拿来与大家共享。

--------------------------------------本文主要包含如下内容:1. Debug 和Release 编译方式的本质区别2. 哪些情况下Release 版会出错2. 怎样“调试” Release 版的程序--------------------------------------关于Debug和Release之本质区别的讨论一、Debug 和Release编译方式的本质区别Debug 通常称为调试版本,它包含调试信息,并且不作任何优化,便于程序员调试程序。

Release 称为发布版本,它往往是进行了各种优化,使得程序在代码大小和运行速度上都是最优的,以便用户很好地使用。

Debug 和Release 的真正秘密,在于一组编译选项。

下面列出了分别针对二者的选项(当然除此之外还有其他一些,如/Fd /Fo,但区别并不重要,通常他们也不会引起Release 版错误,在此不讨论)Debug 版本:/MDd /MLd 或/MTd 使用Debug runtime library(调试版本的运行时刻函数库) /Od 关闭优化开关/D "_DEBUG" 相当于#define _DEBUG,打开编译调试代码开关(主要针对assert函数) /ZI 创建Edi t and continue(编辑继续)数据库,这样在调试过程中如果修改了源代码不需重新编译/GZ 可以帮助捕获内存错误/Gm 打开最小化重链接开关,减少链接时间Release 版本:/MD /ML 或/MT 使用发布版本的运行时刻函数库/O1 或/O2 优化开关,使程序最小或最快/D "NDEBUG" 关闭条件编译调试代码开关(即不编译assert函数) /G F 合并重复的字符串,并将字符串常量放到只读内存,防止被修改实际上,Debug 和Release 并没有本质的界限,他们只是一组编译选项的集合,编译器只是按照预定的选项行动。

dump参数

dump参数

dump参数dump参数是指在计算机程序中用来将数据从内存中转储到外部文件或设备的一种操作。

在软件开发和调试过程中,dump参数常常用于记录程序运行时的状态信息,以便后续分析和排查问题。

本文将从dump参数的定义、使用场景和注意事项等方面进行阐述。

一、dump参数的定义在计算机编程中,dump参数是指将内存中的数据转储到外部文件或设备的操作。

它可以把程序在运行时的状态信息保存下来,以便后续分析和调试。

通过使用dump参数,开发人员可以获取程序在运行过程中的变量值、函数调用栈、异常信息等关键数据,从而更好地理解程序的运行情况。

1. 调试程序:当程序发生异常或崩溃时,使用dump参数可以将程序的状态信息保存下来,以便后续进行调试。

通过分析dump文件,开发人员可以定位问题所在,并进行修复。

2. 性能分析:在对程序进行性能优化时,使用dump参数可以记录程序运行时的性能数据,如CPU占用率、内存使用情况等。

通过分析dump文件,开发人员可以找出性能瓶颈,并进行优化。

3. 安全分析:当程序受到攻击或存在安全漏洞时,使用dump参数可以记录攻击的痕迹和关键信息。

通过分析dump文件,安全专家可以了解攻击者的行为,进而采取相应的安全措施。

4. 数据恢复:在程序运行过程中,如果发生意外情况导致数据丢失或损坏,使用dump参数可以将内存中的数据保存下来,以便后续进行数据恢复。

三、dump参数的注意事项1. dump文件的大小:由于dump文件包含了程序在运行时的所有状态信息,因此文件大小通常会很大。

在使用dump参数时,需要注意磁盘空间是否足够,并确保dump文件的保存路径正确。

2. dump文件的保密性:由于dump文件中包含程序的关键信息,如变量值、函数调用栈等,因此需要妥善保管,避免泄露给未授权的人员。

3. dump文件的分析:分析dump文件需要一定的专业知识和工具支持。

开发人员在使用dump参数时,需要了解如何使用相关工具进行分析,并能够准确地定位问题所在。

linux,人为产生dump文件的方法

linux,人为产生dump文件的方法

linux,人为产生dump文件的方法
在Linux系统中,可以通过以下方法人为产生dump文件:
1. 使用gcore命令:gcore命令可以在运行中的进程中生成一个core 文件,可以用于后续的调试分析。

例如,要生成进程ID为12345的进程的dump文件,可以使用以下命令:
```
gcore 12345
```
该命令将在当前目录下生成一个名为core.12345的dump文件。

2. 使用kill命令:可以使用kill命令发送一个特殊的信号给某个进程,使其生成core文件。

例如,要生成进程ID为12345的进程的dump文件,可以使用以下命令:
```
kill -SIGQUIT 12345
```
该命令将发送SIGQUIT信号给进程,进程会生成一个core文件。

3. 使用gdb调试器:可以使用gdb调试器来附加到一个正在运行的进程,并在其中生成core文件。

首先,使用ps命令找到要调试的进程的进程ID,然后使用gdb命令附加到该进程。

例如,要生成进
程ID为12345的进程的dump文件,可以使用以下命令:
```
gdb -p 12345
```
然后,在gdb的交互界面中,可以使用generate-core-file命令来生成core文件。

无论使用哪种方法,生成的dump文件都可以用于调试和分析程序的崩溃问题。

请注意,在生产环境中,应谨慎使用这些方法,并确保在产生dump文件之前已经备份了重要的数据。

coredump文件的生成方式

coredump文件的生成方式

coredump文件的生成方式
Core dump文件是在程序发生严重错误(如段错误、内存访问
越界等)时,操作系统将程序当前的内存状态以文件的形式保存下
来的一种机制。

生成core dump文件的方式可以通过以下几种途径:
1. 通过ulimit命令设置core dump文件大小限制,可以使用ulimit命令来设置core dump文件的大小限制,使用ulimit -c unlimited命令可以将core dump文件的大小限制设置为无限制,
这样当程序发生错误时就会生成core dump文件。

2. 在程序中使用系统调用设置,在程序中可以通过调用系统函
数来设置生成core dump文件的方式,比如使用ulimit函数设置core dump文件大小限制,或者使用prctl函数设置生成core dump
文件的路径等。

3. 通过操作系统的配置文件设置,在一些操作系统中,可以通
过修改配置文件(如/etc/security/limits.conf)来设置生成
core dump文件的大小限制和路径等参数。

4. 使用特定的调试工具,在调试程序时,可以使用特定的调试
工具(如gdb)来设置程序发生错误时生成core dump文件,通过gdb工具可以设置生成core dump文件的路径和大小限制等参数。

总的来说,生成core dump文件的方式可以通过操作系统的设置、程序中的系统调用、配置文件的修改以及调试工具的使用等途径来实现。

不同的操作系统和调试工具可能会有不同的设置方法,需要根据具体情况进行选择和配置。

Dump文件分析(转发)

Dump文件分析(转发)

Dump⽂件分析(转发)原⽂:本⽂主要介绍Dump⽂件结构,理解Dump⽂件对于分析线程⾼占⽤、死锁、内存溢出等⾼级问题有⾮常重要的指导意义。

什么是Dump⽂件Dump⽂件是进程的内存镜像。

可以把程序的执⾏状态通过调试器保存到dump⽂件中。

Dump⽂件是⽤来给程序编写⼈员调试程序⽤的,这种⽂件必须⽤专⽤⼯具软件打开。

如何⽣成Dump⽂件使⽤命令:jstack pid可以查看到当前运⾏的java进程的dump信息。

Dump⽂件结构⾸先浏览⼀下dump⽂件的⽂本内容:Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.77-b03 mixed mode):"Attach Listener" #37 daemon prio=9 os_prio=0 tid=0x00007f87b42b7000 nid=0x680f waiting on condition [0x0000000000000000]ng.Thread.State: RUNNABLE"Druid-ConnectionPool-Destory-331358539" #36 daemon prio=5 os_prio=0 tid=0x00007f87a4278800 nid=0x67e4 waiting on condition [0x00007f87b8dce000] ng.Thread.State: TIMED_WAITING (sleeping)at ng.Thread.sleep(Native Method)at com.alibaba.druid.pool.DruidDataSource$DestroyConnectionThread.run(DruidDataSource.java:1724)"Druid-ConnectionPool-Create-331358539" #35 daemon prio=5 os_prio=0 tid=0x00007f87a4022000 nid=0x67e3 waiting on condition [0x00007f87ce86a000] ng.Thread.State: WAITING (parking)at sun.misc.Unsafe.park(Native Method)- parking to wait for <0x00000000b3804848> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)at com.alibaba.druid.pool.DruidDataSource$CreateConnectionThread.run(DruidDataSource.java:1629)"Abandoned connection cleanup thread" #31 daemon prio=5 os_prio=0 tid=0x00007f87e0d91800 nid=0x672b in Object.wait() [0x00007f87cd2c2000]ng.Thread.State: TIMED_WAITING (on object monitor)at ng.Object.wait(Native Method)at ng.ref.ReferenceQueue.remove(ReferenceQueue.java:143)- locked <0x00000000b422d1e8> (a ng.ref.ReferenceQueue$Lock)at com.mysql.jdbc.AbandonedConnectionCleanupThread.run(AbandonedConnectionCleanupThread.java:43)"DestroyJavaVM" #30 prio=5 os_prio=0 tid=0x00007f87e0008800 nid=0x670b waiting on condition [0x0000000000000000]ng.Thread.State: RUNNABLE"http-nio-8081-AsyncTimeout" #28 daemon prio=5 os_prio=0 tid=0x00007f87e016e800 nid=0x6727 waiting on condition [0x00007f87b94cf000]ng.Thread.State: TIMED_WAITING (sleeping)at ng.Thread.sleep(Native Method)at org.apache.coyote.AbstractProtocol$AsyncTimeout.run(AbstractProtocol.java:1211)at ng.Thread.run(Thread.java:745)"http-nio-8081-Acceptor-0" #27 daemon prio=5 os_prio=0 tid=0x00007f87e0166000 nid=0x6726 runnable [0x00007f87b95d0000]ng.Thread.State: RUNNABLEat sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422)at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250)- locked <0x00000000b410d480> (a ng.Object)at .NioEndpoint$Acceptor.run(NioEndpoint.java:455)at ng.Thread.run(Thread.java:745)"http-nio-8081-ClientPoller-0" #26 daemon prio=5 os_prio=0 tid=0x00007f87e0292800 nid=0x6725 runnable [0x00007f87b96d1000]ng.Thread.State: RUNNABLEat sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)- locked <0x00000000b410d6c0> (a sun.nio.ch.Util$2)- locked <0x00000000b410d6b0> (a java.util.Collections$UnmodifiableSet)- locked <0x00000000b410d668> (a sun.nio.ch.EPollSelectorImpl)at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)at .NioEndpoint$Poller.run(NioEndpoint.java:793)at ng.Thread.run(Thread.java:745)"http-nio-8081-exec-10" #25 daemon prio=5 os_prio=0 tid=0x00007f87e028c000 nid=0x6724 waiting on condition [0x00007f87b97d2000]ng.Thread.State: WAITING (parking)at sun.misc.Unsafe.park(Native Method)- parking to wait for <0x00000000b410d898> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:103)at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:31)at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)at ng.Thread.run(Thread.java:745)其中每个空⾏⽤于分隔⼀个线程,每个线程的信息是以堆栈信息的⽅式展开,显⽰了⽬前正在调⽤的⽅法以及所在的代码⾏。

dump文件的函数参数

dump文件的函数参数

dump文件的函数参数一、什么是dump文件?dump文件是程序在运行过程中,将内存中的数据以二进制的形式保存到磁盘上的一种文件格式。

它包含了程序在运行过程中的所有内存信息,包括变量的值、函数的调用栈、堆栈信息等。

通过分析dump文件,可以了解程序在运行过程中的状态,帮助程序员快速定位和解决问题。

二、为什么需要使用dump文件?在程序开发过程中,经常会遇到各种各样的bug和崩溃问题。

当程序出现崩溃时,我们通常无法立即找到问题的原因,这时候使用dump文件就非常有帮助了。

通过分析dump文件,可以还原出程序在崩溃时的内存状态,帮助我们定位问题所在。

三、如何生成dump文件?生成dump文件的方法有很多种,下面介绍两种常用的方法:1. 使用操作系统提供的工具:在Windows操作系统中,可以通过配置系统参数或使用命令行工具来生成dump文件。

例如,在Windows 7及以上版本中,可以通过配置系统参数来指定在程序崩溃时自动生成dump文件。

2. 使用调试工具:在程序调试过程中,可以使用调试工具生成dump文件。

例如,在Visual Studio中,可以通过在代码中插入调试断点或使用异常处理机制来生成dump文件。

dump文件的函数参数是指在生成dump文件时,对相关函数的调用所传递的参数信息。

这些参数信息对于分析问题和定位错误非常重要。

下面介绍几个常见的dump文件函数参数:1. 栈指针(Stack Pointer):栈指针是指向程序当前栈帧的指针,它指向了当前函数的返回地址和函数的局部变量。

通过栈指针,可以获取函数的调用栈信息,从而了解函数的调用关系和参数传递。

2. 堆指针(Heap Pointer):堆指针是指向堆内存区域的指针,堆内存是动态分配的内存,例如通过malloc()函数分配的内存。

通过堆指针,可以获取堆内存的状态信息,帮助我们分析内存泄漏等问题。

3. 函数参数(Function Arguments):函数参数是指函数在调用时传递的参数值。

coredump文件考出解析

coredump文件考出解析

coredump文件考出解析Core Dump文件是指在计算机程序运行时,出现异常情况导致程序崩溃时所生成的一种文件。

这个文件记录了程序在崩溃时的内存状态信息,包含了程序运行时的堆栈信息、寄存器状态以及其他相关的调试信息等。

通过分析Core Dump文件,可以帮助开发人员定位和解决程序崩溃的问题。

Core Dump文件的解析对于软件开发人员来说是一项非常重要的技能,可以帮助他们快速定位和修复程序中的bug。

下面就让我们来了解一下Core Dump文件的解析过程吧。

要解析Core Dump文件,我们需要借助一些调试工具。

常用的调试工具有GDB(GNU Debugger)、LLDB(LLVM Debugger)等。

这些工具可以加载Core Dump文件,并提供一系列命令和功能来分析和调试程序。

解析Core Dump文件的第一步是加载文件。

使用调试工具加载Core Dump文件后,我们可以查看文件中的各种信息。

比如,我们可以查看程序崩溃时的堆栈信息,了解程序在崩溃前的执行路径。

通过分析堆栈信息,我们可以确定程序崩溃的位置,找出导致程序崩溃的原因。

除了堆栈信息,Core Dump文件还包含了程序崩溃时的内存状态信息。

我们可以通过查看内存状态,了解程序在崩溃前的变量值、函数调用等信息。

这对于定位程序崩溃的原因非常有帮助。

在解析Core Dump文件时,我们还可以使用调试工具提供的其他功能,比如查看变量的值、设置断点、单步执行等。

这些功能可以帮助我们进一步分析和调试程序。

在进行Core Dump文件解析时,我们需要注意以下几点。

首先,要保证使用的调试工具版本与生成Core Dump文件的程序版本一致,以免出现兼容性问题。

其次,要注意文件的大小,如果Core Dump 文件过大,可能需要分析工具支持加载大文件。

此外,要注意保护好Core Dump文件的安全,避免泄露敏感信息。

除了使用调试工具解析Core Dump文件,还有一些第三方工具和库可以帮助我们更方便地分析Core Dump文件。

dump文件分析2篇

dump文件分析2篇

dump文件分析2篇第一篇:Windows dump文件分析Windows dump文件是一种用来记录系统崩溃信息的文件。

当Windows操作系统遇到蓝屏或其他严重错误时,会自动生成一个dump文件,其中包含系统状态和运行时数据,这对于问题诊断和修复非常重要。

在本文中,我们将介绍如何分析Windows dump文件,以帮助用户解决系统故障和崩溃问题。

一、获取dump文件通常,当Windows发生蓝屏或停机错误时,会在系统重启时自动生成一个dump文件,将其保存在C:\Windows\Minidump文件夹中。

如果用户没有设置该文件夹位置,则dump文件通常位于系统根目录的MEMORY.DMP文件中。

如果没有自动创建dump文件,则可以手动启用Windows内存转储(crash dump)功能,以生成dump文件。

二、分析dump文件通过分析Windows dump文件,我们可以得到以下信息:1、错误代码:告诉我们这次崩溃的是哪种类型的问题。

例如,错误代码0x0000007B表示硬盘损坏或驱动程序异常。

2、异常地址:崩溃时发生错误的代码位置,帮助我们确定问题来自哪个程序或驱动程序。

3、堆栈跟踪:程序崩溃时调用栈的状态。

从最后一个函数返回地址开始,逐个跟踪函数调用过程,以确定程序崩溃的原因。

以下是我们分析dump文件的步骤:1、使用Debugging Tools for Windows工具(例如WinDbg)打开dump文件。

2、在WinDbg中输入“!analyze -v”命令,以查看错误代码和异常地址。

3、使用“kb”命令查看堆栈跟踪,确定哪个驱动程序或应用程序导致崩溃。

4、在Google或Microsoft的搜索引擎中,输入发生错误代码的十六进制值,以查找可能的解决方案和修复。

例如,如果错误代码为0x0000007B,则可能是硬件设备或磁盘问题。

5、根据分析结果采取相应措施。

例如,更新所有驱动程序、检查硬件问题或升级操作系统。

linux coredump机制

linux coredump机制

linux coredump机制Linux coredump机制是一种操作系统的特性,它允许在程序崩溃或异常终止时将程序的内存状态保存到一个称为core文件的特殊文件中。

该文件可以用于了解程序崩溃的原因,进行调试和错误分析。

下面将介绍Linux coredump机制的工作原理、配置方法以及使用core文件进行调试的步骤。

工作原理:当一个程序崩溃或异常终止时,Linux操作系统会默认生成一个core文件,其中包含了程序在崩溃时的内存状态。

生成core文件的过程可以分为三个步骤:1. 内核捕获异常:Linux内核会监视所有运行的进程,当一个进程崩溃或异常终止时,内核会接收到一个异常信号。

2. 内核生成core文件:在接收到异常信号后,内核会为异常进程创建一个core文件,并将进程的内存状态保存其中。

core 文件默认保存在当前工作目录下,文件名通常以"core"开头。

3. 调试器分析core文件:生成core文件后,可以使用调试器(如gdb)加载该文件进行调试。

调试器可以读取core文件中的信息,如程序崩溃时的堆栈信息、寄存器状态等。

通过分析这些信息,可以找出程序崩溃的原因,并进行错误分析和修复。

配置方法:为了生成core文件,需要确保以下两个条件已满足:1. 启用coredump功能:在Linux系统中,默认情况下并不会生成core文件。

要启用coredump功能,需要在系统中执行以下命令:```shellulimit -c unlimited```该命令会将core文件大小限制设置为无限制,从而允许生成任意大小的core文件。

2. 配置core文件存储位置:默认情况下,core文件会保存在当前进程的工作目录中。

可以通过以下方法更改core文件的保存位置:```shellecho "core.%p" > /proc/sys/kernel/core_pattern```上述命令将core文件的命名模式设置为"core.pid",其中pid是进程ID。

Debug版本下能运行而Release下不能运行的问题总结

Debug版本下能运行而Release下不能运行的问题总结

Debug版本下能运⾏⽽Release下不能运⾏的问题总结引⾔如果在您的开发过程中遇到了常见的错误,或许您的Release版本不能正常运⾏⽽Debug版本运⾏⽆误,那么我推荐您阅读本⽂:因为并⾮如您想象的那样,Release版本可以保证您的应⽤程序可以象Debug版本⼀样运⾏。

如果您在开发阶段完成之后或者在开发进⾏⼀段时间之内从来没有进⾏过Release版本测试,然⽽当您测试的时候却发现问题,那么请看我们的调试规则1:规则1: 经常性对开发软件进⾏Debug和Release版本的常规测试. 测试Release版本的时间间隔越长,排除问题的难度越⼤,⾄少对Release版本进⾏每周1不要随意删除ReleaseASSERT和TRACE在Release 例如: ASSERT(m_ImageList.Create(MAKEINTRESOURCE(IDB_IMAGES), 16, 1, RGB(255,255,255))); 这样的代码在Debug模式不会出错,图像列表也⾃动创建了,然⽽在Release版本呢?后继使⽤m_ImageList对象只会造成程序的Crash!,因此ASSERT宏中尽量使⽤逻辑运算符作为验证。

规则 2: 不要将代码放置在仅在某种编译选项中执⾏的地⽅,对于使⽤_DEBUG等编译选项宏内部的代码必须不影响整个程序的使⽤。

规则 3: 不要使⽤规则2作为评判标准来删除ASSERT宏,ASSERT宏是个有⽤的⼯具,但容易使⽤错误. 使Debug编译模式接近Release模式如果您的Release版本存在的问题是由代码被编译器⾃动排除造成的,那么通过这个⽅法您的问题可能会重现. ⼀些问题的产⽣可能是由于不同编译选项之间预定义符号造成的,因此您可以更改编译模式下的预定义符号,从⽽使您的Debug模式接近Release模式,观察错误是否产⽣, 更改编译预定义符号⽅法如下: a.. Alt-F7打开项⽬设置,在C++/C 页⾯,选择"General"类别,更改"_DEBUG"符号为"NDEBUG".b.. 在C++/C 页⾯, 选择"Preprocessor"类别,添加预定义符号"_DEBUG"到"Undefined Symbols"栏.c.. 使⽤"Rebuild All"重新编译如果通过上⾯设置,您在Release编译模式下⾯的问题在Debug模式下重现,那么请您依据以下步骤对您的代码进⾏修改: a.. 查找ASSERT排除其中的所有重要执⾏语句,或者将ASSERT修改为VERIFY. b.. 检查"#ifdef _DEBUG" 内所有代码,排除Release模式使⽤的代码. c.. 查找TRACE 排除其中的所有重要执⾏语句. TRACE和ASSERT⼀样,仅在Debug模式下编译. 如果通过上⾯修改更正了您在Debug模式下的问题,那么您可以重新编译Release模式,⾮常有可能您可以解决先前存在的问题!. 错误的假定造成编译模式错误您是否经常性的假定您的变量或者对象被初试化成某个指定的值(可能0)?您是否假定你所有关联到的资源在应⽤程序中都存在?这些也是Debug和Release模式下不同问题产⽣的原因。

dump参数

dump参数

dump参数dump参数是指在计算机编程中,用于将数据从内存中转储到外部存储介质的一种操作。

它常用于调试和分析程序运行时的数据状态,对于程序员来说是一项非常重要的工具。

下面将从不同的角度来探讨dump参数的作用和使用。

一、dump参数的基本概念和作用在计算机编程中,dump参数是指通过将内存中的数据转储到外部存储介质上,以便于程序员在调试和分析程序运行时的数据状态。

通过使用dump参数,可以将程序在运行过程中的数据状态保存下来,以便于后续的分析和调试工作。

dump参数通常被用于查找程序中的bug,分析程序的性能问题以及进行内存泄漏的检测等。

在不同的编程语言和操作系统中,dump参数的使用方法可能会有所不同。

下面以C语言为例,介绍一下在Linux系统中如何使用dump 参数。

1. 在程序中添加dump参数的代码在C语言中,可以使用库函数如`glibc`中的`abort()`函数来生成dump文件。

当程序运行到某个特定的条件下时,可以调用`abort()`函数来生成dump文件。

例如,可以在程序中添加一个断言,当断言条件不满足时,调用`abort()`函数来生成dump文件。

2. 编译程序时添加相应的选项在Linux系统中,可以通过在编译程序时添加相应的选项来生成dump文件。

例如,可以使用`gcc`编译器的`-g`选项来生成带有调试信息的可执行文件。

然后,当程序运行到某个特定的条件下时,可以使用`gdb`调试工具来生成dump文件。

3. 使用调试工具生成dump文件除了在程序中添加dump参数的代码和编译程序时添加相应的选项外,还可以使用调试工具来生成dump文件。

例如,在Linux系统中,可以使用`gdb`调试工具来生成dump文件。

首先,需要启动`gdb`调试工具并加载可执行文件。

然后,可以使用`generate-core-file`命令来生成dump文件。

三、dump参数的应用场景dump参数在程序开发和调试过程中有着广泛的应用场景。

dump文件分析

dump文件分析

dump文件分析Dump文件是一种记录电脑系统状态的文件,通常被用于分析系统崩溃或错误的原因。

通过分析dump文件,可以帮助我们确定问题的根源,并采取相应的措施来解决它们。

在本文中,我将详细介绍如何进行dump文件分析,包括导出和读取dump文件中的信息,以及如何利用这些信息诊断和解决问题。

首先,我们需要了解如何导出一个dump文件。

当系统遇到错误或崩溃时,会自动生成一个dump文件,通常位于Windows系统的Minidump文件夹中。

要导出dump文件,可以按照以下步骤进行操作:1. 打开“控制面板”,选择“系统和安全”。

2. 选择“系统”,然后点击“高级系统设置”。

3. 在“高级”选项卡下,点击“设置”。

4. 在“启动和故障恢复”部分,点击“设置”按钮。

5. 在“系统故障”部分,将“写入调试信息”设置为“小型内存转储”。

6. 点击“确定”来保存更改。

一旦dump文件生成,我们可以使用调试工具来读取和分析它。

Windows操作系统提供了一个名为WinDbg的调试工具,可以用来分析和调试dump文件。

以下是一些基本的WinDbg命令,帮助我们读取和分析dump文件中的信息:1. 打开WinDbg工具,选择“文件”->“打开转储文件”。

2. 导航到dump文件的位置,选择并打开它。

3. 使用“!analyze -v”命令来执行自动分析。

这将提供有关崩溃的基本信息,如错误代码和崩溃地址。

4. 使用其他命令如“!thread”,“!process”,“!stacks”等来获取更详细的信息,如线程、进程和堆栈信息。

通过分析dump文件中的信息,我们可以确定崩溃的原因。

常见的dump文件分析包括以下几个方面:1. 异常信息分析:通过查看异常代码和异常地址,我们可以了解到底发生了什么类型的异常,以及它是在哪个模块中发生的。

这可以帮助我们锁定问题的范围,并有针对性地解决。

2. 线程堆栈分析:通过查看线程的堆栈信息,我们可以定位到代码中引起问题的具体位置。

各种dump方法

各种dump方法

各种dump⽅法dump的⽅法很多,各有特点,都应该掌握。

dump分为两种:⽤户进程dump、系统dump。

先说⽤户进程的dump。

最简单的是在Win7的任务管理器中右键点击进程,选择Create Dump File。

完成之后会弹出对话框说明dump⽂件的位置。

这对于死锁进程的调试有帮助。

⽤WinDbg也很⽅便。

WinDbg是绿⾊版,直接拷贝整个⽬录即可使⽤。

可以Attach到任意的进程中,然后⽤命令.dump xxx.dmp即可。

WinDbg提供了⼀个⽅便的脚本,可以直接取运⾏中进程的dump,完成后⾃动detach,尽量减少对运⾏中进程的影响,⽅便分析CPU 占⽤过⾼、死锁等问题:adplus.vbs -hang -p 1234 -o d:\dump另外⼏个⽤法:adplus -crash -pn w3wp -quiet 抓w3wp进程,crash模式,当那个进程崩溃结束的时候⾃动抓取当时的内存adplus -hang -iis -quiet 抓IIS相关进程,包括其上host的web应⽤,以及iis⾃⾝WinDbg本⾝也是查看分析dump⽂件的最常见⼯具,直接打开dump⽂件即可。

分析dump的常⽤命令:!analyze -v 显⽰所有分析所需的常⽤信息。

k/kb 显⽰调⽤堆栈。

.ecxr 显⽰当前执⾏状态。

.lastevent 查看上⼀个事件(异常也是事件的⼀种)执⾏WinDbg.exe -I会把WinDbg安装成默认的异常处理程序。

如果某个程序崩溃,则⾃动调⽤WinDbg进⼊调试状态。

这时候可以⽅便的取dump。

如果安装了VS2005、VS2008,也可以作为默认的debugger,在Option⾥⾯可以设置。

进程崩溃启动VS后,可以从菜单中选取dump 功能。

以上都是⽤户进程的dump⽅法,下⾯介绍系统dump(摘抄):Dump⽂件有三种:完整内存转储,内核内存转储,⼩内存转储。

System Properties中的⾼级选项中可以看到这些设置。

VC调试版(DebugVersion)和发行版(ReleaseVersion)

VC调试版(DebugVersion)和发行版(ReleaseVersion)

VC调试版(DebugVersion)和发⾏版(ReleaseVersion)调试是纠正或修改代码,使之可以顺利地编译、运⾏的过程。

为此,VC IDE提供了功能强⼤的调试和跟踪⼯具。

1.1.1 调试版(Debug Version)和发⾏版(Release Version)开发环境总是为你的⼯程创建调试版和发⾏版。

在调试版⾥,我们排查各种可能的程序错误,然后制作成发⾏版以获得较好的信息。

这就是调试版与发⾏版的区别:前者包含了较多调试信息,最终执⾏⽂件较⼤,性能较差;后者最终执⾏⽂件较⼩,性能更好。

具体地讲,发⾏版和调试版区别有:1. 调试版下,可以使⽤诊断和跟踪宏,如ASSERT和TRACE,MFC类的DUMP功能也定义在调试版下。

2. 额外的变量初始化。

编译器会⾃动将你未初始化的变量逐每字节赋值为0xCC。

3. 内存分配监视。

在调试版下,在堆上分配的内存都会记录,做额外的初始化(0xCD),在释放时,会将其内容逐字节置0xFD。

怎样配置调试版或发⾏版?调试版和发⾏版都可以从 Build | Configurations中增加,或者当这两个配置已存在的情况下,从Project | Settings命令下进⾏配置。

两者在配置上主要有以下不同:1. 两个版本应该配置成不同的输出⽂件夹。

这在Project | Settings | General中的两个编辑框中设定。

2. 调试版下,程序应该链接Debug版的c运⾏时库、禁⽌代码优化,并在C++属性页中的Preprocessor类别中加上预定义标识符_DEBUG。

在Link属性页中的Debug类别中,选中DebugInfo和Microsoft Format选框。

4. 发⾏版下,程序应该链接Release版的c运⾏时库、设置代码优化,不定义_DEBUG标识符,去掉DebugInfo选框中的选择。

1.1.2 排除编译错误VC6.0的编译器可以报告⼤约1100个左右的错误,这还不包含警告。

gdb调试coredump文件

gdb调试coredump文件

gdb调试coredump⽂件
linux上程序崩溃起来挺烦⼈,不过linux ⽐较好的是有gdb.
1、⽣成coredump⽂件
echo"ulimit -c unlimited" >> /etc/profile
然后记得敲⼊命令
source /etc/profile
然后敲⼊命令:
ulimit –c
效果如下:
确认能否⽣成coredump⽂件,使⽤如下命令(使⽤时注意,我在测的时候会直接退出当前⽤户)
kill -s SIGSEGV $$
然后回到执⾏上述命令的路径下即可看到coredump⽂件,我这边⽣成的⽂件名为core.3477,依个⼈会随机⽣成不同的数字。

2、调试coredump⽂件
调试⽅式为: gdb program coredump⽂件
例如我的可执⾏⽂件为test, ⽣成的coredump⽂件为core.3533,则命令如下:
gdb test core.3533
显⽰如下图所⽰:
嗯,有的⼈运⽓好,直接就显⽰源代码了,如果你像我⼀样,接着⽤下⾯的命令
backtrace
打印堆栈信息。

我们看到最接近崩溃的地⽅在第8⾏
然后调⽤命令
frame 8
直接找到源代码的位置:。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

在Windows平台下用C++开发应用程序,最不想见到的情况恐怕就是程序崩溃,而要想解决引起问题的bug,最困难的应该就是调试release版本了。

因为release版本来就少了很多调试信息,更何况一般都是发布出去由用户使用,crash 的现场很难保留和重现。

目前有一些方法可以解决:崩溃地址+ MAP文件;MAP 文件;SetUnhandledExceptionFilter + Minidump。

本文重点解决Minidump方式。

一、Minidump文件生成1、Minidump概念minidump(小存储器转储)可以理解为一个dump文件,里面记录了能够帮助调试crash的最小有用信息。

实际上,如果你在系统属性-> 高级-> 启动和故障恢复-> 设置-> 写入调试信息中选择“小内存转储(64 KB)”的话,当系统意外停止时都会在C:\Windows\Minidump\路径下生成一个.dmp后缀的文件,这个文件就是minidump文件,只不过这个是内核态的minidump。

我们要生成的是用户态的minidump,文件中包含了程序运行的模块信息、线程信息、堆栈调用信息等。

而且为了符合其mini的特性,dump文件是压缩过的。

2、生成minidump文件通过drwtsn32、NTSD、CDB等调试工具生成Dump文件,drwtsn32存在的缺点虽然NTSD、CDB可以完全解决,但并不是所有的操作系统中都安装了NTSD、CDB等调试工具。

根据MiniDumpWriteDump接口,完全可以程序自动生成Dump文件。

3、自动生成Minidump文件当程序遇到未处理异常(主要指非指针造成)导致程序崩溃死,如果在异常发生之前调用了SetUnhandledExceptionFilter()函数,异常交给函数处理。

MSDN中描述为:Issuing SetUnhandledExceptionFilter replaces the existing top-level exception filter for all existing and all future threads in the calling process.因而,在程序开始处增加SetUnhandledExceptionFilter()函数,并在函数中利用适当的方法生成Dump文件,即可实现需要的功能。

生成dump文件类(minidump.h)#pragma once#include<windows.h>#include<imagehlp.h>#include<stdlib.h>#pragma comment(lib, "dbghelp.lib")inline BOOL IsDataSectionNeeded(const WCHAR* pModuleName){if(pModuleName == 0){return FALSE;}WCHAR szFileName[_MAX_FNAME] = L"";_wsplitpath(pModuleName, NULL, NULL, szFileName, NULL);if(wcsicmp(szFileName, L"ntdll") == 0)return TRUE;return FALSE;}inline BOOL CALLBACK MiniDumpCallback(PVOIDpParam,const PMINIDUMP_CALLBACK_INPUT pInput,PMINIDUMP_CALLBACK_OUTPUTpOutput){if(pInput == 0 || pOutput == 0)return FALSE;switch(pInput->CallbackType){case ModuleCallback:if(pOutput->ModuleWriteFlags & ModuleWriteDataSeg)if(!IsDataSectionNeeded(pInput->Module.FullPath))pOutput->ModuleWriteFlags &= (~ModuleWriteDataSeg);case IncludeModuleCallback:case IncludeThreadCallback:case ThreadCallback:case ThreadExCallback:return TRUE;default:;}return FALSE;}//创建Dump文件inline void CreateMiniDump(EXCEPTION_POINTERS* pep, LPCTSTR strFileName) {HANDLE hFile = CreateFile(strFileName, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);if((hFile != NULL) && (hFile != INVALID_HANDLE_VALUE)){MINIDUMP_EXCEPTION_INFORMATION mdei;mdei.ThreadId = GetCurrentThreadId();mdei.ExceptionPointers = pep;mdei.ClientPointers = FALSE;MINIDUMP_CALLBACK_INFORMATION mci;mci.CallbackRoutine =(MINIDUMP_CALLBACK_ROUTINE)MiniDumpCallback;mci.CallbackParam = 0;MINIDUMP_TYPE mdt = (MINIDUMP_TYPE)0x0000ffff;MiniDumpWriteDump(GetCurrentProcess(), GetCurrentProcessId(), hFile, MiniDumpNormal, &mdei, NULL, &mci);CloseHandle(hFile);}}LPTOP_LEVEL_EXCEPTION_FILTER WINAPIMyDummySetUnhandledExceptionFilter(LPTOP_LEVEL_EXCEPTION_FILTER lpTopLevelExceptionFilter){return NULL;}BOOL PreventSetUnhandledExceptionFilter(){HMODULE hKernel32 = LoadLibrary(_T("kernel32.dll"));if (hKernel32 == NULL)return FALSE;void *pOrgEntry = GetProcAddress(hKernel32, "SetUnhandledExceptionFilter");if(pOrgEntry == NULL)return FALSE;unsigned char newJump[ 100 ];DWORD dwOrgEntryAddr = (DWORD) pOrgEntry;dwOrgEntryAddr += 5; // add 5 for 5 op-codes for jmp farvoid *pNewFunc = &MyDummySetUnhandledExceptionFilter;DWORD dwNewEntryAddr = (DWORD) pNewFunc;DWORD dwRelativeAddr = dwNewEntryAddr - dwOrgEntryAddr;newJump[ 0 ] = 0xE9; // JMP absolutememcpy(&newJump[ 1 ], &dwRelativeAddr, sizeof(pNewFunc));SIZE_T bytesWritten;BOOL bRet= WriteProcessMemory(GetCurrentProcess(), pOrgEntry, newJump, sizeof(pNewFunc) + 1, &bytesWritten);return bRet;}LONG WINAPI UnhandledExceptionFilterEx(struct_EXCEPTION_POINTERS*pException){TCHAR szMbsFile[MAX_PATH] = { 0 };::GetModuleFileName(NULL, szMbsFile, MAX_PATH);TCHAR* pFind = _tcsrchr(szMbsFile, '\\');if(pFind){*(pFind+1) = 0;_tcscat(szMbsFile, _T("CreateMiniDump.dmp"));CreateMiniDump(pException,szMbsFile);}// TODO: MiniDumpWriteDumpFatalAppExit(-1, _T("Fatal Error"));return EXCEPTION_CONTINUE_SEARCH;}//运行异常处理void RunCrashHandler(){SetUnhandledExceptionFilter(UnhandledExceptionFilterEx);PreventSetUnhandledExceptionFilter();}//测试实现文件// 一个有函数调用的类//class CrashTest{public:void Test(){Crash();}private:void Crash(){// 除零,人为的使程序崩溃//int i = 13;int j = 0;int m = i / j;strcpy(NULL,"adfadfg");}};int_tmain(int argc, _TCHAR* argv[]){//设置异常处理函数RunCrashHandler();CrashTest test;test.Test();getchar();return 0;}注意事项1、需要配置debug选项,在C/C++选项→常规→调试信息格式(设置为程序数据库(/Zi));在连接器选项—>调试→生成调试信息(设置为是);C/C++选项→优化→禁用。

相关文档
最新文档