嵌入式开发——程序跑飞原因总结

前言

在嵌入式软件开发中，程序跑飞是一个比较棘手的问题。为什么说棘手，那是因为当程序跑飞时，往往没有任何错误信息报出来，Log停止的地方通常也不是出现问题的地方，因此这让我们很难定位问题。
基于以上原因，我将嵌入式开发中一些常见的程序跑飞原因以及相关解决方案记录在这篇博客下。

程序跑飞的原因与相关解决方案

1. 栈溢出
说明：这可能是最常见的问题了，往往是因为我们定义了较大的局部变量，使得栈空间不够了。
解决方案：使用static关键字或者将局部变量定义为全局变量。

2. 访问了不该访问的内存
说明：这个问题也是比较常见的，通常由于指针使用不当造成的。
解决方案：这个我也没啥办法，只能仔细检查一下代码中的指针了。

3. 程序运行时，将内存中重要的数据覆盖了
说明：这个问题遇到的比较少。如果往错误的地址写了数据，导致重要数据被覆盖，程序自然跑不起来了。
解决方案：这个一般也与指针使用不当有关，还是好好检查指针的使用吧。

4. 代码中有死循环
说明：这属于笔误型的错误，例如以下代码。
for(i = 0; i < j; j++)
这样的语句编译不会报错，但程序会一直在这循环。
解决方案：这种错误一旦发生是很难发现的，我只能建议写代码时多注意一些。

5. 编译问题
说明：一般来说，这个问题发生的场景为，程序员小A终于把程序跑飞的问题解决掉了，妥善起见，他把修改的代码保存了。小A在后续开发中又遇到了一些问题，代码被他改的不像样。于是，他将代码回退到以前的版本编了一把，编完后他发觉这个版本的程序跑飞问题还没有解决。小A想，还好我有备份，于是他把自己的备份文件替换了原文件，重新编译，结果，程序又跑飞了。这是为什么呢？难道小A之前没有把程序跑飞问题解决掉吗？
其实不是的，这个问题是由编译器的“增量编译”导致的。我们注意到小A把代码回退后先编了一把，然后才替换的文件，这个时候，如果小A的备份文件中有一些文件的日期比被替换文件的早，那么再次编译时，编译器就不会编译它们。
解决方案：修改一下备份文件的注释什么的，更新一下文件日期，然后再次编译。

这些就是我目前所记录下的有关程序跑飞的原因了，至于我写的解决方案，我其实觉得意义不大，聊胜于无吧。因为这类问题难就难在如何定位，定位到了错误后解决起来还是很快的。至于如何定位问题，我一般先把自己添加、修改的代码改回去或者注释掉，然后再一点一点把它们加上，加到哪一段发现出错了，那就定位到了。
以上是我的个人经验，若有不当之处欢迎大家指出，大家有其他情况补充也可以在评论区留言。