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，文件句柄超出，内存泄露等。