MTK死机bug大全

死机bug 一、一个编译开关引发的血案：（此问题耗时本菜鸟1周排查出来） 问题主要涉及到以下文件：(橙色为新增加部分) 1，FLYFOT_FEATURES.h： #define _FT_SMS_DOUBLE_LINE_INBOX_ 2，MMI_features.h： #include "FLYFOT_FEATURES.h" 3，mmi_msg_context.h： typedef struct { unsigned short msgtype; unsigned char storageType; unsigned char startseg; unsigned char totalseg; unsigned char timestamp[7]; unsigned char number[21]; #ifdef _FT_SMS_DOUBLE_LINE_INBOX_ unsigned char sms_content[MMI_SMS_MINI_STORED_CONTENT_SIZE]; #endif unsigned short ref; unsigned short startindex; #ifdef __UNIFIED_MESSAGE_BACKGROUND_SEND_SUPPORT__ unsigned char send_status; #endif #if defined(__UNIFIED_MSG_SUPPORT__) && !defined(__UNIFIED_MESSAGE_LOW_MEMORY_SUPPORT__) unsigned short content[MMI_SMS_MAX_MMI_STORED_CONTENT_SIZE]; #endif #ifdef __MSG_SMS_EMAIL_SUPPORT__ unsigned char pid; #endif #ifdef __EMS_NON_STD_7BIT_CHAR__ unsigned char dcs; #endif } mmi_frm_sms_msgbox_struct; 4，mmi_msg_context.c：（没有#include "MMI_features.h"） mmi_frm_sms_msgbox_struct mmi_frm_sms_msg_box[MMI_SMS_MAX_MSG_NUM]; 5，SMSUtil.c：（有#include "MMI_features.h"） mmi_ucs2ncpy((S8*) mmi_frm_sms_msg_box[addindex].sms_content, (S8*) data->sms_content,MMI_SMS_MINI_STORED_CONTENT_SIZE/2 - 1); /* 由于此文件有#include "MMI_features.h"，所以_FT_SMS_DOUBLE_LINE_INBOX_开关在mmi_frm_sms_msgbox_struct里有效，所以. sms_content部分 可以编译通过，但是由于之前没有内存分配，运行时则会越界。。 就MTK 6225平台而言，大部分的xxx .c文件，通常都有包含#include "MMI_features.h"，也就是说，在修改.h时候，并不会遇到编译开关打开了却“无效”或“部分文件有效、部分文件无效”的问题。 而在 .../MTK_08A40/custom/common文件夹下，一些.c文件，可能由于客户化关系，并没有包含#include "MMI_features.h", 那么当需要修改或扩展此文件夹下的.h中的结构体时（并且使用了编译开关）， 应该检查其对应的变量声明处(对应的.c文件)有无包含#include "MMI_features.h"，此文件夹比较特殊，请大家引起注意。 死机bug 二、MMI TASK 栈内存爆掉 void F1(void) { U8 tmp_buf[512]; U8 i ; for(i=0;i<512;i++) { tmp_buf[i] = 0; } } 此函数的执行会导致手机重启。 如果将512修改为256，则没有问题了。 此问题的原因是栈内存爆掉了，想必是程序在调用该函数之前，已经调用了一些函数，并且已经使用了许多的栈内存。 MTK平台 MMI TASK的stack size 通常定义为2k。 死机bug 三、MMI Quece爆掉 短信按姓名排序 void mmi_frm_sms_create_sms_list(void) { for (i = 0; i < g_frm_sms_cntx.mmi_frm_sms_msg_box_size; i++) { sort_by_name_done(i); } } 由于按姓名排序需要拼音比较、号码匹配等较为复杂的操作，所用算法又是效率极低的冒泡排序法。所以比较耗时，排序1条时间近0.1秒。 故，完成3000条短信排序，需要几分钟的时间，这样执行时，MMI TASK一直被占用，导致MMI QUEUE爆掉。 这个问题的最终解决方法是，将冒泡排序算法改为堆排序。时间大大缩短，仅为3秒，问题得解。 死机bug 四、 History栈爆掉 static S16 increment(void) { ++currHistoryIndex; MMI_ASSERT(currHistoryIndex < MAX_HISTORY); //history 栈超过30！！ return currHistoryIndex; } 分析： 重复进行信箱排序，途径的界面为： 1，inbox list界面。 2，inbox option界面。 3，排序选择界面。 4，Processing处理界面。 5，inbox msg 阅读界面。 这是一个循环，所以中间的任意界面的history都在不停的压栈，弹栈。 原来代码里没有对SCR_ID_MSG_INBOX_OPTION，SCR_ID_MSG_INBOX_MSG，SCR_ID_MSG_SMS_SORT_INBOX_SETTING界面进行弹栈操作，致使每进行一次循坏操作，栈内id就会累加，导致栈最终爆掉。 解决方法，使得每次entryscreen 某一个Scr_ID的时候，都DeleteScreenIfPresent(Scr_ID); 达到进入屏幕A之前，必先清除屏幕A，保持history 栈里始终至多有一个屏幕A，问题得解。 死机bug 五、常规死机问题 1，数组长度越界。 2，数据类型越界。 3，0作为"/"或"%"。 4，文件句柄超出，内存泄露等。