[Windows CE]debug正常,release不正常,你遇到了吗?
反正我是遇到了,而且还遇到了多次. 曾经一度困扰了很久,终于都一一解决仂.现在回过头来看,其实,问题并不是想象中那么妖,如果自己一开始就能保持一颗用头脑思考的心的话,其实不用这么长时间的.
卡住仂,下次继续更新 .
OK.GO ON.
除了一些显示的#ifdef DEBUG 之类的手误导致的mistake之外,最常见的问题就是TIMING了.
有人说:DEBUG下大家一起慢,RELEASE大家一起快,为什么还会有不同的时序出现呢?
回答:没错,的确大家都变快了,但是变快的步伐是不一定一致的!
很多在DEBUG下,因为各种串口输出以及debug版本的内核,会隐藏很多其实是有问题的代码. 貌似正常了,其实不然. 比如我上次遇到的一个问题: A和B都要互斥的访问一个资源(CSPI),并且在不同的进程空间里,所以需要加mutex进行资源访问保护. A先初始化CSPI(CSPI_A配置),然后利用CSPI进行一些操作.然后B初始化,B插进来一脚获得CSPI的控制权限,又重新配置了CSPI(CSPI_B配置).此时,A如果要对CSPI访问的话,只能干瞪眼看着B在做.那么,如果要让A下次能继续做的话,B在做完自己的事情之后,应该把CSPI的配置恢复程CSPI_A.这样,才能神不知鬼不觉的让A继续往下做.当时,脑子一些短路了,恢复程配置B的那段代码没有放在mutex的保护区域内!!!但是这样的代码,在DEBUG下没有问题,而RELEASE就发现不正常了.
还好这个错误犯的比较明显,代码又都是在一块,仔细review一下就能发现不对了.那么下一个问题就没有这么明显了.
串口的收发是一个很经典的互斥问题(MD,又是互斥).不过因为是在同一进程里(device.exe),所以也就不用mutex了,直接用critical_section即可.其实问题的原因就是临界值保护的不恰当了.author的想法是正确的,但是在发函数里明显被无数个错误处理给混乱了.直接导致的现象就是RELEASE下一切正常的时序到了release下就不行了. 找到这个原因花了很长的时间,现在总结下来原因有2: 一,钻牛角尖了.总以为是自己写的那部分代码有错误; 二, 经验不足.没能一直往正确的方向PUSH.
这些个问题解决了,加上前段时间折腾的SUSPEND问题,我有了一些感触:
1 问题的产生都是有蛛丝马迹的,找到凶器往往是破案的开始;
2 不要对任何代码持绝对的相信,也不要对自己任何的能力持任何的否定;
3 能解决出现的问题是最好,但是事前的异常处理机制就应该完善.
卡住仂,下次继续更新 .
OK.GO ON.
除了一些显示的#ifdef DEBUG 之类的手误导致的mistake之外,最常见的问题就是TIMING了.
有人说:DEBUG下大家一起慢,RELEASE大家一起快,为什么还会有不同的时序出现呢?
回答:没错,的确大家都变快了,但是变快的步伐是不一定一致的!
很多在DEBUG下,因为各种串口输出以及debug版本的内核,会隐藏很多其实是有问题的代码. 貌似正常了,其实不然. 比如我上次遇到的一个问题: A和B都要互斥的访问一个资源(CSPI),并且在不同的进程空间里,所以需要加mutex进行资源访问保护. A先初始化CSPI(CSPI_A配置),然后利用CSPI进行一些操作.然后B初始化,B插进来一脚获得CSPI的控制权限,又重新配置了CSPI(CSPI_B配置).此时,A如果要对CSPI访问的话,只能干瞪眼看着B在做.那么,如果要让A下次能继续做的话,B在做完自己的事情之后,应该把CSPI的配置恢复程CSPI_A.这样,才能神不知鬼不觉的让A继续往下做.当时,脑子一些短路了,恢复程配置B的那段代码没有放在mutex的保护区域内!!!但是这样的代码,在DEBUG下没有问题,而RELEASE就发现不正常了.
还好这个错误犯的比较明显,代码又都是在一块,仔细review一下就能发现不对了.那么下一个问题就没有这么明显了.
串口的收发是一个很经典的互斥问题(MD,又是互斥).不过因为是在同一进程里(device.exe),所以也就不用mutex了,直接用critical_section即可.其实问题的原因就是临界值保护的不恰当了.author的想法是正确的,但是在发函数里明显被无数个错误处理给混乱了.直接导致的现象就是RELEASE下一切正常的时序到了release下就不行了. 找到这个原因花了很长的时间,现在总结下来原因有2: 一,钻牛角尖了.总以为是自己写的那部分代码有错误; 二, 经验不足.没能一直往正确的方向PUSH.
这些个问题解决了,加上前段时间折腾的SUSPEND问题,我有了一些感触:
1 问题的产生都是有蛛丝马迹的,找到凶器往往是破案的开始;
2 不要对任何代码持绝对的相信,也不要对自己任何的能力持任何的否定;
3 能解决出现的问题是最好,但是事前的异常处理机制就应该完善.
