转：

Data storage interrupt Register:0x0000000b
Task:0xc844f0 " *** " -- 通过这个参数，可以知道是哪个任务出现的异常

具体定位提示：
1、可以使用“checkStack”命令看是否产生了堆栈溢出：如果是 *** 任务的队战溢出，则在checkStack的打印中， *** 的堆栈状态会显示成“overflow”
2、可以使用tt命令查看任务调用栈，通过分析调用栈的每一层函数，尝试找原因，参照上面的可能的原因部分
3、分析函数调用序列中所访问的全局变量（尤其是指针和数组），看是否存在任务抢占而导致全局指针被修改或者访问无效指针的问题。


3、重现问题，如果通过上述步骤无法直接找到原因，那么恭喜你，你已经遇到恐怖的随机内存改写问题，这类问题通常难以重现，而且通过分析单个任务的运行轨迹很难找到原因，这类问题很可能的情况是：虽然任务A在运行函数FuncA时产生的异常，但真正的内存改写代 *** 很可能是在任务X或函数FuncX中，解决这类问题的关键是如何重现问题，一旦问题可以比较容易的重现，那么可以说问题已经解决了一半。

重现问题的办法：
1、回忆先前的 *** 作步骤，一步一步地重做一遍，看问题是否可以重现

2、如果是任务A产生的异常，则人工制造一些条件，使任务A不断的运行，以重现问题，通过脚本或者打桩，不断地发一些消息触发任务A的运行，这是最常用的方法，如果A是周期运行，则缩短周期，加快运行

3、逆向分析，通过分析代 *** ，可能怀疑一些代 *** 有问题，这时候，可以针对 *** 的创造各种人为条件来重现问题，例如怀疑某个定时器可能存在重复进入和重复删除，则可以人为修改代 *** 流程，使之进入定时器重复进入/重复删除流程，或者用脚本不断地创建和删除定时器，以加快问题出现的频率

4、手动调整任务优先级，分析任务抢占相关的问题，在基本确定任务异常可能和任务抢占相关的情况下，可以尝试以各种组合，将几个相关的任务优先级调整成相同的优先级（这样，这几个任务就不会再产生任务抢占了）。在此基础上尝试重现问题；如果在优先级相同的情况下异常不再出现，则说明这几个任务之间所共享的变量存在互斥问题；否则说明该问题很可能和互斥无关，或者根据需要把某些优先级调高，某些调低，以重现任务抢占的问题。


4、解决问题

1、如果找到料问题所在，则直接修改问题
2、如果通过多日的重现和定位，都无法找到真正的原因，那么没有办法的办法就是：直接修改代 *** ，把怀疑有问题的地方全部改掉，然后再测试看问题是否解决。我曾经遇到一个任务异常的问题，如果跑1个测试脚本，则平均跑7-8小时可以出现一次，跑7个测试脚本，则平均跑半小时就会出现一次，定位了一个多月度找不到真正原因，花了很多时间用来想办法重现异常，写脚本。。后来没有办法只好把怀疑的地方全部改掉，之后跑7个脚本共48小时没有出现异常，最后解决问题，，之后反过来推导root cause，最后找到原因。

-------------------------------------------------------------------------------------------------------------------------------------------------------------------