关于用MAP文件定位异常行

lovelyzuzu 2009-09-25 03:57:42


我的工程生成了map文件，异常不定时发生，一天或者几天才发生一次，我不知道出错在什么地方，出错后，我看系统日志的内存地址是0x00008432，这个地址对应我的map文件中的实际地址是不是该0x00408432呢？

我假设是这样的，我去map中找该地址就应该是出在函数SendWork中，对吧；
然后计算偏移位置用

0x00408432-004078a0=B92

如果还要减基址0x1000这样岂不是为负数了吗？这样计算不是有问题了吗？
下面是我的map文件部分，望大师协助分析下。


Address Publics by Value Rva+Base Lib:Object
0001:00006740 ?Init@@YAXPAUDeviceID_t@@@Z 00407740 f Send_Sub.obj
0001:00006810 ?DrawMain_Info@@YAXPAUSEND_STRUCT@@@Z 00407810 f Send_Sub.obj
0001:000068a0 ?SendWork@@YAXPAUSEND_STRUCT@@PAUAcs_Evt_t@@@Z 004078a0 f Send_Sub.obj
0001:00007890 ?ReciveWork@@YAXPAUSEND_STRUCT@@@Z 00408890 f Send_Sub.obj


Line numbers for .\Release\Send_Sub.obj(C:\test\Send_Sub.cpp) segment .text

163 0001:000028d0 165 0001:000028e2 167 0001:000028ec 169 0001:00002932
170 0001:00002952 174 0001:00002972 176 0001:0000298e 177 0001:000029a6
178 0001:000029b0 180 0001:000029ba 182 0001:000029d7 186 0001:000029ea
188 0001:00002a0c 190 0001:00002a1f 192 0001:00002a37 193 0001:00002a4f

.............................................................................
............................................................................
4359 0001:0000b4c0 4368 0001:0000b4ce 4371 0001:0000b4d0 4373 0001:0000b4df
4376 0001:0000b4e0 4389 0001:0000b4f1 4392 0001:0000b509 4394 0001:0000b525
4398 0001:0000b530 4399 0001:0000b546 4407 0001:0000b56a 4408 0001:0000b57b
4412 0001:0000b590 4413 0001:0000b5a7 4414 0001:0000b5ee
...全文
381 18 打赏 收藏 转发到动态 举报
写回复
用AI写文章
18 条回复
切换为时间正序
请发表友善的回复…
发表回复
klkvc386 2009-09-30
  • 打赏
  • 举报
 回复
Mark
凤矶 2009-09-30
  • 打赏
  • 举报
 回复
晕，这么久了还没FIX
0x00008432换成0x00408432你没加0X1000，换回去怎么就减0X1000.
根本就不用换来换去。
lovelyzuzu 2009-09-30
  • 打赏
  • 举报
 回复
到底种说法对啊，这两种说法的出入比较大哦。今天又出现了一次。
野男孩 2009-09-30
  • 打赏
  • 举报
 回复
[Quote=引用 14 楼 lovelyzuzu 的回复:]
到底种说法对啊，这两种说法的出入比较大哦。今天又出现了一次。
[/Quote]

你现在map文件有，代码有，错误地址有，那就两种方法各试一次不就知道哪种正确了。
xylicon 2009-09-26
  • 打赏
  • 举报
 回复
应该是SendWork。

另外计算偏移位置应该是0x00408432-00400000 - 1000=7432
野男孩 2009-09-26
  • 打赏
  • 举报
 回复
出错函数是这个：?SendWork@@YAXPAUSEND_STRUCT@@PAUAcs_Evt_t@@@Z 004078a0 f Send_Sub.obj

位置在SendWork函数开始处偏移为0xb92的地方，不用再减0x1000了，map后面这个地址是已经加过0x1000了的。

lz可以看看我的这篇blog:

实战：结合Dr.Watson系统日志和Vc6来定位多线程环境下程序异常退出的错误
url:http://blog.csdn.net/coding_hello/archive/2008/09/29/2994158.aspx
lovelyzuzu 2009-09-25
  • 打赏
  • 举报
 回复
我还发现一个问题，我编译的是会出这样的结果
Linking...
LINK : error : Internal error during EmitMap
ExceptionCode = C0000005
ExceptionFlags = 00000000
ExceptionAddress = 0043F8A4
NumberParameters = 00000002
ExceptionInformation[ 0] = 00000000
ExceptionInformation[ 1] = 00CC8F44
CONTEXT:
Eax = AAAAAAAB Esp = 0012F8F4
Ebx = 77C10E13 Ebp = 77C10E13
Ecx = 00CC8F40 Esi = 3FFF0000
Edx = 3FFFA5B8 Edi = 00000020
Eip = 0043F8A4 EFlags = 00010202
SegCs = 0000001B SegDs = 00000023
SegSs = 00000023 SegEs = 00000023
SegFs = 0000003B SegGs = 00000000
Dr0 = 0012F8F4 Dr3 = 77C10E13
Dr1 = 77C10E13 Dr6 = 00CC8F40
Dr2 = 00000000 Dr7 = 00000000
Error executing link.exe.
Tool execution canceled by user.


但是clear之后再编译又没有了，不知这个对分析问题有没有用。
lovelyzuzu 2009-09-25
  • 打赏
  • 举报
 回复
谢谢各位热心帮助，

那个帮我解答下这个问题“
ReceiveWork的入口地址是00408890， 比0x00408432大，为什么还是这个函数出的错呢，我觉得应该是上面的函数SendWork@@YAXPAUSEND_STRUCT@@PAUAcs_Evt_t@@@Z 004078a0 ”
chenyu2202863 2009-09-25
  • 打赏
  • 举报
 回复
[Quote=引用 7 楼 marrco2005 的回复:]
可以用 MiniDumpWriteDump 输出dump 文件

这里有一篇文章，共分4个部分，讲的很好，你可以看一下
http://www.codeproject.com/KB/debug/XCrashReportPt1.aspx?fid=25022&df=90&mpp=25&noise=3&sort=Position&view=Quick&select=2483700#xx2483700xx
[/Quote]

顶，现在都这种方式了~
不过我还知道一种查看寄存器的方法来定位~

看看这个
http://www.codeproject.com/KB/debug/crash_report.aspx

bobohack 2009-09-25
  • 打赏
  • 举报
 回复
http://blog.csdn.net/bobohack/archive/2008/12/04/3442455.aspx
marrco2005 2009-09-25
  • 打赏
  • 举报
 回复
可以用 MiniDumpWriteDump 输出dump 文件

这里有一篇文章，共分4个部分，讲的很好，你可以看一下
http://www.codeproject.com/KB/debug/XCrashReportPt1.aspx?fid=25022&df=90&mpp=25&noise=3&sort=Position&view=Quick&select=2483700#xx2483700xx
lovelyzuzu 2009-09-25
  • 打赏
  • 举报
 回复
我生成的有pdb文件，程序崩溃的时候输出的dump文件在那里设置呢？
marrco2005 2009-09-25
  • 打赏
  • 举报
 回复
在编译程序的时候生成 pdb 文件，程序崩溃的时候输出 dump 文件，用 windbg 程序调试dump 文件，运气好的话可以直接定位到出错的源代码
lovelyzuzu 2009-09-25
  • 打赏
  • 举报
 回复
ReceiveWork的入口地址是00408890， 比0x00408432大，为什么还是这个函数出的错呢，应该是上面的函数SendWork@@YAXPAUSEND_STRUCT@@PAUAcs_Evt_t@@@Z 004078a0
的地址才对吧.
岁月小龙 2009-09-25
  • 打赏
  • 举报
 回复
首先计算下边的值：崩溃地址 – 首选加载地址 - 0x1000。
首选加载地址一般是0x00400000，除非是dll
0x00408432-0x00400000 - 0x1000 =0x7432

找第一个比0x7432大的数是0000b4c0，看它的前一行，是193
所以是第193行出错了。
greatws 2009-09-25
  • 打赏
  • 举报
 回复
函数void __cdecl ReciveWork(struct SEND_STRUCT *) 的问题，看0001:00007890就行了，后面00408890 = 00007890+00401000。

然后再结合汇编看看是空指针还是什么造成的。
凤矶 2009-09-25
  • 打赏
  • 举报
 回复
可以确定是ReciveWork里面出了问题。不过，没有PDB文件想定位太难了些。
MS-VC-使用MAP文件快速定位程序崩溃代码行-VC++
作为程序员，平时最担心见到的事情就是程序发生了崩溃，无论是指针越界还是非法操作，都将给我们的应用系统造成巨大的损失。...我们更为关心的是程序中的哪一行导致了系统崩溃，这样我们才能有针对性的进行改正。
VS中通过map文件找到崩溃的代码行
3. **计算崩溃地址**：使用Map文件中的起始地址加上异常偏移值，可以计算出实际的崩溃地址。例如，如果起始地址是0x4e2000，异常偏移是0x21，则崩溃地址为0x4e2021。 4. **定位崩溃位置**：在Map文件的“Rva+Base”...
MAP文件详细解析
这些信息对于调试程序至关重要，特别是在发生异常崩溃的情况下，MAP文件能够帮助开发者精确定位问题所在的具体代码行。 #### 三、MAP文件的作用 1. **崩溃定位**：当程序出现非法操作或崩溃时，可以通过分析MAP...
VS+MAP文件（崩溃地址定位崩溃行）
本教程将围绕“VS+MAP文件（崩溃地址定位崩溃行）”这一主题，详细讲解如何通过VS和MAP文件来定位崩溃发生的具体位置。 首先，我们需要理解MAP文件的作用。在编译和链接过程中，MAP文件被生成，它包含了程序的内存...
VC的Map文件定位程序
只要可以通过在VC中启用Map输出功能，就可以在生成目录产生Map文件，如果程序崩溃。通过这个工具可以帮助通过崩溃地址找到错误大概位置
VC/MFC

16,551

社区成员

421,605

社区内容

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Creator Browser
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了，记忆之中，与CSDN的年龄几乎差不多。随着时间的推移，MFC技术渐渐的偏离了开发主流，若干年之后的今天，当我们面对着微软的这个经典之笔，内心充满着敬意，那些曾经的记忆，可以说代表着二十年前曾经的辉煌……
        向经典致敬，或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天，我们期待着MFC技术能够恢复其曾经的辉煌，或许这个期待会永远成为一种“梦想”，或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代，期待更好的互联网技术能够使得MFC技术框架得以重现活力，……

试试用AI创作助手写篇文章吧

+ 用AI写文章