没有发现ASSERT信息,只有stack dump信息。起初听他们描述,感觉像是QQ或者通话的问题。
抓了TRACE之后,发现是MED模块的问题,由于MED主要是一些媒体文件的解码。
由于观察现象时发现,通话时,还没有来得及响铃,就开始重启,因此可以大概推知是来电振铃出了问题,
具体出在什么地方,需要查找TRACE信息。从别人那里获取的TRACE信息如下:
Trace 1745424 150706 MOD_NIL TRACE_ERROR [1] fatal error (4): Data_abort - MED
Trace 1745424 150706 MOD_NIL TRACE_ERROR Exception type: data abort
Trace 1745424 150706 MOD_NIL TRACE_ERROR software version:
E500_A.1.4
Trace 1745424 150706 MOD_NIL TRACE_ERROR boot mode: normal mode
Trace 1745424 150706 MOD_NIL TRACE_ERROR rtc sec = 16, rtc min = 33, rtc hour = 1
Trace 1745424 150706 MOD_NIL TRACE_ERROR rtc day = 1, rtc mon = 1, rtc wday = 1, rtc year = 9
Trace 1745424 150706 MOD_NIL TRACE_ERROR execution unit: MEDMED
Trace 1745424 150706 MOD_NIL TRACE_ERROR status: 0x00000000
Trace 1745424 150706 MOD_NIL TRACE_ERROR stack pointer: 0x00169380
Trace 1745424 150706 MOD_NIL TRACE_ERROR stack dump:
Trace 1745424 150706 MOD_NIL TRACE_ERROR 0x085569C9
Trace 1745424 150706 MOD_NIL TRACE_ERROR 0xA0001BED
Trace 1745424 150706 MOD_NIL TRACE_ERROR 0x085569C9
Trace 1745424 150706 MOD_NIL TRACE_ERROR 0x085569C9
Trace 1745424 150706 MOD_NIL TRACE_ERROR 0x08480FD5
Trace 1745424 150706 MOD_NIL TRACE_ERROR 0x0847CE59
Trace 1745424 150706 MOD_NIL TRACE_ERROR 0x084DE0EF
Trace 1745424 150706 MOD_NIL TRACE_ERROR 0x0866D4D3
Trace 1745424 150706 MOD_NIL TRACE_ERROR 0x0845E407
Trace 1745424 150706 MOD_NIL TRACE_ERROR 0x0866D4A1
Trace 1745424 150706 MOD_NIL TRACE_ERROR number of messages in the external queue: 0
Trace 1745424 150706 MOD_NIL TRACE_ERROR messages in the external queue:
Trace 1745424 150706 MOD_NIL TRACE_ERROR MSG_ID_INVALID_TYPE
Trace 1745424 150706 MOD_NIL TRACE_ERROR MSG_ID_INVALID_TYPE
Trace 1745424 150706 MOD_NIL TRACE_ERROR MSG_ID_INVALID_TYPE
Trace 1745424 150706 MOD_NIL TRACE_ERROR MSG_ID_INVALID_TYPE
Trace 1745424 150706 MOD_NIL TRACE_ERROR MSG_ID_INVALID_TYPE
Trace 1745424 150706 MOD_NIL TRACE_ERROR MSG_ID_INVALID_TYPE
Trace 1745424 150706 MOD_NIL TRACE_ERROR MSG_ID_INVALID_TYPE
Trace 1745424 150706 MOD_NIL TRACE_ERROR MSG_ID_INVALID_TYPE
观察TRACE,结合BUG描述,可以大致推知是MED的振铃问题,具体位置需要看catcher打印的栈信息。
有些人遇到这个信息,就蒙了,感觉无从下手,我最早学习MTK时,也是无从下手,总觉得这样的信息没有ASSERT直观
,一看就知道哪个文件哪一行出错。但ASSERT并不总是金牌,有一次遇到一个MEMCPY的ASSERT,调用的地方太多,
照样需要查栈信息来寻找问题。当然写的代码,尽量在一些关键的地方加上ASSET,这会让人查找问题更轻松一些。
当然有了这个信息,我们也可以大概推测出BUG的地方和原因的。要查找这个error的信息,必须要找到该软件版本对应
的sym文件。该sym和BIN文件同步生成,都位于BUILD文件下。该文件储存了ARM编绎器为软件中所有函数生成的地址。
而出错时,MTK会保存当时栈中最近执行的10条指令的地址,我们通过对这些地址的研究,就可以找到出错的地方。
由于sym文件只保存了函数的地址,函数体里执行的代码地址没有列出,而一般打出的错误地址不会正好对应某个函数的
地址,一般会会偏移N个单位。当然也有例外,我曾遇到一次出错,有一个地址正好和某函数地址对应。对于出错信息
的地址与函数地址不对应的情况,我推测应该是函数体里的指令出错,所以应查找比该出错指令小且最近的函数。
比如上例行“Trace 1745424 150706 MOD_NIL TRACE_ERROR 0x085569C9”,我们在sym文件中不应该查找0x085569C9
对应的指令,因为一般会一个也找不到,我们要查找x085569C或者x085569对就的函数,这时大约可以查到许多函数,
找到与该出错地址最近且比该地址小的地址对应的函数,十个地址大约可以找到十个左右的函数,通过仔细排查,
确认以下函数:
med_int_left_size
med_int_sfreeaud_main
aud_tts_play_req_hdlr
med_int_smalloc
med_set_ext_memory_pool
TCC_Task_Shell
如此可以大致确定问题出处和原因了,请教项目负责人,知道aud_tts_play_req_hdlr
是语音王的播放函数,在呼入时,有来电报号,该功能和QQ都是从MED栈上动态分配内存,由于QQ占用了一部内存,有呼入电话时,语音王分配内存失败,导到语音解码故障。问题一下解决。
=====================================================================================
呵呵,通过map信息,来查找导致问题的函数入口,是最常用的调试手段之一。其实,
也完全可以通过现象分析来查找问题点。比如,这种完全能复现的问题,很容易找到固定路径的。
如来电提示改为震动,或者无声,会怎样,关闭来电报号,会怎样。一下问题点就出来了。共享内存导致的这个问题,
其实是设计时候的欠考虑,没有考虑到各种可能常见的边界。 Assert用得太多也未必好,作为一种调试手段,
如果都出厂了,还到处Assert或重启来处理一些问题,显得太那个了吧,太不健壮了