寻找崩溃的真相

寻找崩溃的真相
http://www.21tx.com 2002年07月29日 Blog zhengyun_ustc

寻找崩溃的真相

Article last modified on 2002-7-28

----------------------------------------------------------------

The information in this article applies to:

-          C/C++

-          Microsoft Visual C++ 6.0(SP5)

----------------------------------------------------------------

我们来演示一下如何制造一起崩溃事件:

我把这个试验的源代码列出来:

const int x =10000;

int main(int argc, char* argv[])

{

       int *y=0;

       y=(int*)&x;

       *y=10;

       return 0;

}

 

我们用Microsoft Visual C++ 6.0(SP5)编译出一个Debug版本的EXE。双击运行它。在Windows 2000 Server下,你将会得到这样一个对话框:

标题:“Pointer.exe – 应用程序错误”;

正文:“”0x00401279”指令引用的”0x0043101c”内存。该内存不能为”written”。

要终止程序,请单击”确定”。

要调试程序,请单击”取消”。

   知道了这些信息后,如何找到错误发生策源地呢?

   请记住这个地址“0x00401279”,它是崩溃发生地。

如何找到崩溃的源头:

   有两种情况:

µ        一是我们拥有源代码,可以现场调试;

µ        二是现场绝对不可以安装VC,无法调试,但是我们有它的MAP文件。

   第一种情况,有源代码,这被叫做“事后调试”:

首先我们用VC IDE装载这个工程,按F11执行它,切换至反汇编窗口(Disassembly)。

   按下Ctrl+G热键。

   你就会得到一个“Go To”的窗口。默认选择是“Address”。在“Enter address expression”编辑框中输入崩溃发生地0x00401279。然后点击“Go To”按钮。你就来到了这个地方:

00401279   mov         dword ptr [eax],0Ah

好了,我们看到了发生崩溃时执行的是这行反汇编代码,但是为什么会崩溃呢?

我们在这里设置一个断点,按F5来到这里。

在Watch窗口中键入“@EAX”察看EAX寄存器,得到的数值是“0xcccccccc”。显然这是因为向一个空指针指向的地址复制一个数据,从而造成了崩溃。

好了,针对这个问题,你已经调试成功了。

还有一个问题,对于Release版本的EXE,也可以这么调试吗?

当然可以。同样是这个例子,运行它的Release版本,得到的崩溃地址是0x0040108a。

我们在VC中装载这个工程的Release版本,按F11运行它。

来到它的反汇编代码的0x004018a处,我们看到:

0040108A   mov         dword ptr ds:[40B0D0h],0Ah

 

第二种情况,有映射文件Pointer.map:

值得注意的是,如果你只在VC Project Setting对话框中打开Generate mapfile,还是不够的。因为你一定还要输出程序代码地址和源代码行号!!这非常的重要!

要得到这些信息,请在Project Options对话框中键入“/mapinfo:lines /mapinfo:exports”。请你一定要养成这种习惯!因为这不是默认设置。

我们得到的map文件大致如下,我删节了大多数输出:

Pointer

(应用程序名)

 Timestamp is 3d4407a7 (Sun Jul 28 23:03:03 2002)

(时间戳)

 Preferred load address is 00400000

(最佳装载基地址。非常重要的一个数据。不过一般都是这个数。)

 

Address         Publics by Value              Rva+Base     Lib:Object

 

0001:00000250       _main                      00401250 f   Pointer.obj

(_main的虚地址)

 

Line numbers for .\Debug\Pointer.obj(E:\ Pointer\Pointer.cpp) segment .text

 

12 0001:00000250    14 0001:00000268    15 0001:0000026f    16 0001:00000276

18 0001:0000027f    20 0001:00000291    23 0001:000002a4    24 0001:000002a6

(这就是我们的Pointer.cpp所对应的程序代码行号和相对虚拟地址的对应表)

我们可以从中看到,最佳装载基地址是0x00400000,_main的虚地址是0x00401250,而0001:00000250又是什么意思呢?

0x00000250就是_main的相对虚拟地址(RVA)。

0x00010000就是PE头文件的大小,一般都是这个数。

所以虚地址就是这么算出来的:

0x00401250 = 0x00400000     + 0x00010000     +  0x00000250

虚地址      = 最佳装载基地址 + PE头文件的大小 + 相对虚拟地址(RVA)

通过_main的RVA的计算,我们也就知道了怎么计算崩溃地址0x00401279的RVA,是0x00000279,对吧?

然后,在这个MAP映射文件的“Line numbers for .\Debug\Pointer.obj(E:\ Pointer\Pointer.cpp) segment .text”这个行号段中查找这个地址。如你所看到的,只有16行对应的00000276和18行对应的0000027F,没有00000279呀?

没有17行的对应关系,说明17行是空行。

那么00000279就一定是16行的了!这样你不用看那个程序员的代码,就可以通知他:崩溃发生在你的Pointer.cpp的第16行了!很酷吧!

 

Written by zhengyun@tomosoft.com

 

### 关于深度学习中的ERROR999999错误 对于提到的`ERROR999999`,该特定编号并未在常见的深度学习框架文档或社区报告中被广泛识别。然而,基于处理各种深度学习环境中遇到的不同类型的错误的经验,可以推测此错误可能涉及多个方面。 #### 可能的原因分析 1. **软件包兼容性问题** 如果使用的不同库版本之间存在不兼容情况,则可能导致难以预料的行为甚至抛出未知编号的异常。例如,在使用PyTorch时,确保其与CUDA以及cuDNN之间的版本相互匹配至关重要[^2]。 2. **硬件资源不足** 当计算设备(如GPU)内存不足以支持当前模型及其数据集规模时,可能会触发内部逻辑判断并返回非标准错误码。这同样适用于CPU运算场景下物理RAM容量不够的情况。 3. **配置文件解析失败** 若项目依赖某些外部配置项而未能成功加载相应参数设定,亦或是路径指定有误等情况发生时,程序执行流中断前生成自定义编码作为反馈也是合理的解释之一。 4. **第三方插件冲突** 类似于提及到先前安装Visual Studio组件影响后续CUDA正常运作的情形[^4],任何额外引入但未经充分测试验证过的扩展都可能是潜在风险源。 5. **底层驱动层面障碍** 显卡制造商提供的图形处理器驱动程序更新不当或者本身存在问题也会间接造成应用程序崩溃,并伴随不明所以的结果输出。 #### 推荐排查步骤 为了有效定位具体成因进而采取针对性措施: - 审视最近所做的更改操作,包括但不限于新增功能模块、修改现有算法结构等; - 尝试简化输入样本直至最小可重现案例以便更好地观察现象特征变化趋势; - 利用调试工具深入探究函数调用栈信息从而锁定可疑位置所在范围; - 查阅官方论坛及GitHub Issues页面寻找相似经历分享者所提出的建议对策; 最后值得注意的是,当面对完全陌生且缺乏明确描述指引的错误提示时,保持耐心细致的态度往往能够帮助更快地接近真相
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值