博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
在RELEASE版本中快速定位DATA ABORT的方法
阅读量:5862 次
发布时间:2019-06-19

本文共 5562 字,大约阅读时间需要 18 分钟。

首先在DEBUG版本中定位DATA ABORT的方法,地球人应该都知道了吧,我就不废话了。PlatformBuilder或VS2005、EVC这类IDE工具会在DEBUG模式下自动停在出错的那句,情况就很显然了。

RELEASE版本下的泄漏就要稍微麻烦一点,如何快速定位呢?

案例一:用EVC编译的应用程序泄漏

首先我做了一个内存泄漏的程序walzer_leak.exe,里面做了一个泄漏的函数

void DoLeak()
    int* p = (int*)0x81000000;
    *p = 10;
}

编译的时候注意先在project settings里的Link页里勾选“Generate mapfile”,会生成一个map文件。如下图

把编译出来的RELEASE版本可执行文件放到CE5平台下运行。出错的时候串口打印了一句

Data Abort: Thread=83ad1d38 Proc=820266d0 'walzer_leak.exe'

AKY=00000021 PC=00011008(walzer_leak.exe+0x00001008) RA=00011030(walzer_leak.exe+0x00001030) BVA=81000000 FSR=0000000d

这句是系统自动输出的。我们得到了一个关键的信息:PC指针。和PC指针在walzer_leak.exe中的偏移量。然后打开编译时生成的walzer_leak.map文件

,文件不长,我贴一下

************************************************************

Walzer_leak

 Timestamp is 46fcbb17 (Fri Sep 28 16:28:07 2007)

 Preferred load address is 00010000

 Start         Length     Name                   Class

 0001:00000000 00000258H .text                   CODE
 0002:00000000 00000014H .xdata                  DATA
 0002:00000014 00000014H .idata$2                DATA
 0002:00000028 00000014H .idata$3                DATA
 0002:0000003c 00000010H .idata$4                DATA
 0002:0000004c 0000000cH .idata$6                DATA
 0002:00000058 00000000H .edata                  DATA
 0003:00000000 00000010H .idata$5                DATA
 0003:00000010 00000004H .CRT$XCA                DATA
 0003:00000014 00000004H .CRT$XCZ                DATA
 0003:00000018 00000004H .CRT$XIA                DATA
 0003:0000001c 00000004H .CRT$XIZ                DATA
 0003:00000020 00000004H .CRT$XPA                DATA
 0003:00000024 00000004H .CRT$XPZ                DATA
 0003:00000028 00000004H .CRT$XTA                DATA
 0003:0000002c 00000004H .CRT$XTZ                DATA
 0003:00000030 00000009H .bss                    DATA
 0004:00000000 00000038H .pdata                  DATA
 0005:00000000 00000010H .rsrc$01                DATA
 0005:00000010 00000000H .rsrc$02                DATA

  Address         Publics by Value              Rva+Base     Lib:Object

 0001:00000000       ?DoLeak@@YAXXZ             00011000 f   Walzer_leak.obj

 0001:00000010       WinMain                    00011010 f   Walzer_leak.obj
 0001:0000002c       WinMainCRTStartup          0001102c f   corelibc:pegwmain.obj
 0001:000000a0       _cinit                     000110a0 f   corelibc:crt0dat.obj
 0001:00000210       exit                       00011210 f   corelibc:crt0dat.obj
 0001:00000228       _XcptFilter                00011228 f   coredll:COREDLL.dll
 0001:00000238       __C_specific_handler       00011238 f   coredll:COREDLL.dll
 0001:00000248       LocalFree                  00011248 f   coredll:COREDLL.dll
 0002:00000014       __IMPORT_DESCRIPTOR_COREDLL 00012014     coredll:COREDLL.dll
 0002:00000028       __NULL_IMPORT_DESCRIPTOR   00012028     coredll:COREDLL.dll
 0003:00000000       __imp___C_specific_handler 00013000     coredll:COREDLL.dll
 0003:00000004       __imp_LocalFree            00013004     coredll:COREDLL.dll
 0003:00000008       __imp__XcptFilter          00013008     coredll:COREDLL.dll
 0003:0000000c       \177COREDLL_NULL_THUNK_DATA 0001300c     coredll:COREDLL.dll
 0003:00000010       __xc_a                     00013010     corelibc:crt0init.obj
 0003:00000014       __xc_z                     00013014     corelibc:crt0init.obj
 0003:00000018       __xi_a                     00013018     corelibc:crt0init.obj
 0003:0000001c       __xi_z                     0001301c     corelibc:crt0init.obj
 0003:00000020       __xp_a                     00013020     corelibc:crt0init.obj
 0003:00000024       __xp_z                     00013024     corelibc:crt0init.obj
 0003:00000028       __xt_a                     00013028     corelibc:crt0init.obj
 0003:0000002c       __xt_z                     0001302c     corelibc:crt0init.obj
 0003:00000030       __onexitend                00013030     <common>
 0003:00000034       __onexitbegin              00013034     <common>
 0003:00000038       _exitflag                  00013038     <common>

 entry point at        0001:0000002c

 Static symbols

 0001:0000010c       doexit                     0001110c f   corelibc:crt0dat.obj

************************************************************

OK,首先,里面有一句“Preferred load address is 00010000”,这意味着DATA ABORT那句的PC=00011008(walzer_leak.exe+0x00001008) 我们必须把括

号里的0x1008加上这个load address的偏移量,得到0x11008(注意不能直接用PC,一会儿再给个案例就知道了),然后我们在函数偏移列表里看Rva+Base

这栏,找到0x11008落在了DoLeak函数的地址范围里,所以是DoLeak函数泄漏了。

案例二:在OAL层做了一个泄漏的函数,用Platform Builder进行RELEASE版编译并LINK到NK.exe里,然后应用程序Call_Leak.exe调用该函数导致泄漏

步骤类似,只是Platform Builder默认就会在RELEASE目录下生成.map文件。应用程序去调用泄漏的OAL函数时,出现

Data Abort: Thread=822fc000 Proc=820267c0 'Call_Leak.exe'

AKY=00000041 PC=8023e3c8(NK.EXE+0x0003e3c8) RA=8023e1d4(NK.EXE+0x0003e1d4) 
BVA=8e000000 FSR=00000005

注意我们这次是NK.EXE里制造泄漏,所以PC指针不是在0x00011008这样的Slot 0低地址了,而是在0x80000000以上的KERNEL区域了。

nk.map很长,我选择关键段落来贴

************************************************************

 kern

 Timestamp is 46fca696 (Fri Sep 28 15:00:38 2007)

 Preferred load address is 00010000

 ...

 0001:0003d2c8       OALIoCtlHal_GetDeviceId    0004e2c8 f   oal_ioctl:deviceid.obj
 0001:0003d398       OALIoCtlHal_DoLeak    0004e398 f   oal_ioctl:leaktest.obj
 0001:0003d438       OALIoCtlHal_DdkCall        0004e438 f   oal_io:ioctl.obj
 ...
************************************************************

所以 NK.EXE + 0x0003e3c8 = 0x10000(Preferred load address) + 0x0003e3c8 = 0x4e3c8, 落在了OALIoCtlHal_DoLeak函数里

结论:原理上很简单,就是利用DATA ABORT消息中的PC值,配合MAP文件可以快速定位到泄漏的函数。定位到之后,嘿嘿,谁LEAK谁请客咯。
-------------------------------
10月11日补充:
用上文的方法,不但网友kevin没有成功定位到泄漏的原因(见后面回帖,他定位到微软USBFN的MDD层代码),我这项目组里的人也没抓到原因(定位到PRIVATE下LoadLibrary函数相关的代码)。昨晚我想了下,这个方法的确有漏洞,早上我做了个试验,建立个DialogBox,主处理函数如下
static DWORD* g_pTest = NULL;

int CALLBACK LeakProc(HWND hDlg, UINT uMsg, WPARAM wParam, LPARAM lParam)

{
    switch(uMsg)
    {
    case WM_INITDIALOG:
        g_pTest = (DWORD*)malloc(1);
        break;
    case WM_COMMAND:
        switch(wParam)
        {
        case ID_LEAK:
            *((int*)0x1A013860) = 0x1C000000;
            break;
        case ID_CLOSE:
            if(g_pTest)
            {
                *g_pTest = 1;
            }
            EndDialog(hDlg, 0);
            break;
        }
        break;
     }
     return FALSE;
}
我运行了几次,每次该进程的BaseAddr = 0x1A000000, 而 &g_pTest = 0x1A013860,在进程的全局变量区;malloc之后g_pTest = 0x00030230在进程的堆区。所以我
(1) 在ID_LEAK按钮按下后,模拟一次内存泄漏,直接对&g_pTest地址上的数值改写,把malloc后的0x00030230改成0x00000000, 注意虽然该处已经泄漏了,但是并没有产生data abort exception.
(2) 然后在ID_CLOSE按钮按下后,装做不知道前面那处泄漏,代码风格严谨地先判断下指针是否为空,然后试图在malloc得到的堆区0x00030230地址上写个值,但是由于g_pTest这个指针已经被改写为指向其他进程空间了,所以在*g_pTest = 1这句产生data abort exception并停下来了。
(3) 所以,按照上文的方法,只能抓到*g_pTest = 1这句泄露,而实际上这句是无辜的,真正的元凶*((int*)0x1A013860) = 0x1C000000这句却没有被抓出来。

本文转自Walzer博客园博客,原文链接:http://www.cnblogs.com/walzer/archive/2007/09/28/909626.html,如需转载请自行联系原作者

你可能感兴趣的文章
除了模拟手术教学,VR在医疗领域如何应用?
查看>>
盘点5款Ubuntu监控工具解决CPU暴增问题
查看>>
java 测试IP
查看>>
用CSS做导航菜单的4个理由
查看>>
NOIP2015 运输计划 二分答案+Tarjan LCA+树上差分
查看>>
基本信息项目目标文档
查看>>
移动开发Html 5前端性能优化指南
查看>>
silverlight style和template 使用之tip
查看>>
Eclipse配置python环境
查看>>
Import declarations are not supported by current JavaScript version--JavaScript版本不支持导入声明...
查看>>
js兼容性大全
查看>>
晶振不起振的原因及其解决方法
查看>>
《利用python进行数据分析》学习笔记--数据聚合与分组(groupby)
查看>>
C++中的函数指针模板
查看>>
2015年个人总结
查看>>
C#编程(六)------------枚举
查看>>
《系统架构师》——操作系统和硬件基础
查看>>
如何看待一本图书
查看>>
oracle参数列表
查看>>
Wordpress3.2去除url中的category(不用插件实现)
查看>>