MTK重启问题

MTK重启问 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 重启冻屏解决思路 主要分为两大类问题:一类是重启，一类是冻屏 参考文档ExceptionHandling_V0.9.pdf 一(冻屏 1.1 常见导致冻屏的原因 1.1.1 死循环 如果watch dog未开，那么死循环会导致一直冻屏 如果watch dog开，则等一段时间会重启 1.1.2 在某界面清除了所有按键处理函数 这样会导致按键无反应，但实际上系统还在正常运行 1.1.3 信号量/事件/互斥体 锁死 这种问题一般是两个进程间交互出现的问题，进程A等待进程B完成，但由于种种原因， 进程B这段代码没有得到执行 1.1.4 中断不起作用 二(重启 1.1 常见重启的原因 1.1.1 软件触发的系统错误 1.1.1.1 Software Assertion Failure 程序本身在逻辑上为了避免一些非法执行，遇到这些不应该出现的情况，强制重启 可用的宏ASSERT(), EXT_ASSERT(), and EXT_ASSERT_DUMP() 比如: icontext_button *dm_get_button(U16 index) { /*----------------------------------------------------------------*/ /* Local Variables */ /*----------------------------------------------------------------*/ /*----------------------------------------------------------------*/ /* Code Body */ /*----------------------------------------------------------------*/ MMI_ASSERT(index < DM_MAX_BUTTONS);/*如果index大于等于 DM_MAX_BUTTONS ，则说明传进来的index有错误，直接重启*/ return &dm_button_array[index]; } 1.1.1.2 System Software Fatal Error 一些情况如资源耗尽(如动态内存不足)，消息队列满(可能是任务优先级指派不合适导致， 或者队列太小)，内存混乱，除0等问题会导致system fatal error 比如指针非法，释放野指针等， 1.1.2 CPU触发的系统错误 1.1.2.1 Undefined Instruction Exception When ARM core comes across an instruction that it cannot handle, it takes the undefined instruction trap. 1.1.2.2 Software Interrupt Exception The software interrupt instruction (SWI) is used to enter Supervisor mode, usually to request a particular supervisor function 1.1.2.3 Pre-fetch / Data Abort Exception 当前的内存访问不能完成导致。 可能有内存拷贝越界会导致此类问题。 1.1.3 其他 栈溢出(一般来说应该是函数调用级别太深，导致压栈太多;函数的参数可能传入了结构， 数组，而不是相应的指针;函数的局部数组太大，这几种情况都会导致栈溢出)， 1.2 系统错误处理流程 1.3分析异常 如果能从模拟器复现，最好从模拟器上跟踪调试解决，如果在模拟器不能复现，则需要使用catcher。 1.3.1 复现问题，抓取log，尽量找到规律 1.3.2 分析catcher log 1.3.2.1 由log初步确定重启类型 可以从ExceptionHandling_V0.9.pdf中查具体的error code信息 1.3.2.2 根据stack dump找出最近的函数调用序列 通常情况下，stack dump保存了最近10个函数调用栈，10个函数地址，可以根据此地址在map 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf (*.list文件)中找到相应的函数。 1.3.2.3 分析相应的代码 根据函数调用序列分析相应的代码 如果是assert，会在trace log中直接查看到相应的文件和行号，则直接分析相应的代码就可以了 1.4其他 1.4.1 ctrl buffer问题 我们可以在找规律的时候可以先打开ctrl buffer的监控，输入”*#3366463#”，然后进入”Profiling”菜单，进入”Memory Monitor”菜单，将”Memory Profiling”切换为”OSL”，这样可以在屏幕左上角实时显示ctrl buffer的状态， 例如最开始可能显示如下: 8 200 45 16 100 28 32 100 8 (比如这个,代表32个字节大小的ctrl buffer最多有100个，当前使用了8个) 64 210 52 128 81 8 256 68 6 512 32 1 1024 26 0 2048 51 0 注意一下做了什么操作或者进入什么应用或者来了什么事件后，会导致当前使用数量会增大很多，且不会恢复回来，这样能比较有针对性。 如果是极限值不够，可以相应的增加ctrl buffer，在ctrl_buff_pool.h中修改。 如果是内存泄露导致，则需要查内存泄露的地方 1.4.2 没有接catcher手机重启后的处理 可以在重启后，连接上catcher，选择菜单Advanced—Retrieve exeception，然后点read，把重启log读取出来，然后分析 1.4.3 冻屏 有时候一直停在冻屏界面，我们可以使用Advanced -- Assert Target来让手机重启然后观察task情况，一般结合memory dump使用 有可能是UI_lock_double_buffer/UI_unlock_double_buffer没有配对使用导致 1.4.4 分析界面 层的问题 有些界面问题需要在手机上复现，可以使用Gdi snapshot来抓取屏幕分析各个层的内容 1.4.5 越界问题 静态:需要找一下大致规律，在关键的地方加一些log，确认某些特定重要的全局变量会被覆盖掉，找到这个被覆盖掉的变量在map表(*.lis文件)中的位置，然后往前找看附近是否有较大的数组有可能在操作中存在越界的问题。 动态: 1.4.6 栈溢出的处理 如果是由于函数参数不合适，如传入了大的结构体，可以修改为指针方式，如果是函数里面的局部变量(如数组)太大，则应该修改这些地方的使用方式。 如果是由于函数调用级别太深导致，那么应该将task的stack改大: 在sysgen1.pl中，custom_comp_config_tbl里面是自定义task的地方，这里可以修改栈 的大小，对于系统预定义task，可以在custom_config_task_stack_size中修改 1.4.7 队列满的处理 如果是由于队列太小导致，可用将队列改大一些，如果是由于优先级导致消息不能及时处理导致的队列满，可以修改task的优先级。 可以在sysgen1.pl中修改，custom_comp_config_tbl里面是自定义task的地方。custom_config_task_extq_size是修改系统预定义task的地方。 1.4.8 指针 释放野指针，释放空指针，申请为0的内存，申请的内存不足，动态内存越界 ) (strcpy,memcpy… 1.4.9 nvram 1.4.10 Assert failed MODIS 一些库里面的Assert，需要从modis上跟踪一下是从什么地方调出来的，可以将modis_lib里面的oscar.lib里的osc_platform_print_msg 函数替换掉 例如: signed int osc_platform_print_msg ( const char *format, ... ) { int dbggg = 0; va_list args; va_start(args, format); if(strstr(format,"Assert fail")) { dbggg = dbggg*2; } va_end(args); return 0; }