问题：
该问题由某客户提出，发生在 STM32F103TBU6 器件上。据其工程师讲述：在其产品设计中，软件的架构采用 IAP Loader+App 的模式。IAP Loader 部分负责管理和更新 App 部分，而 App 部分则负责常规的业务的处理，两部分代码分别由独立的软件工程生成。系统运行时先启动 IAP Loader，由其判断是否需要更新 App，如不需更新则跳转到 App，由 App 进行常规业务处理。在软件调试过程中，其软件工程师发现从 IAP Loader 到 App 的跳转存在某种不可靠性。该跳转在某些时候可以完成预设的功能，即启动 App 运行，而另外的一些情况下则会导致程序跑飞。而该跳转的结果又与一些看似不相关的事物相关联，比如，在中断向量表的末端加入一个多余的向量，或将某个全局变量变更一下定义的位置都会应响到该跳转的结果是成功还是跑飞。该工程师对此颇为不解。由于其在异地，只能通过电话沟通，但从话语中可以感受到浓重的疑惑与震惊，不亚与当年麦哲伦发现地球是圆的而带来的惊叹：怎么会这样？！


调研：
从其软件中提取出负责跳转的代码，如表（一）




将该函数做两处修改：
1． 在行(1)的前端加关键字 register
2． 交换行(2)与行(3)的位置

修改后，代码如表（二）：



用将修改后的代码替换原工程中的对应的代码，重新测试。发现，修改后的程序每次都能做出正确的跳转，不再受其它代码行的增减、变更的影响。

结论：
堆栈的变更导致局部变量失效，引用已失效的变量进一步造成严重的错误，属于典型的软件逻辑漏洞。


处理：
修改软件代码，如表（二）。

建议：
有时，问题的复杂程度，有时跟你看问题的角度有关。记得早年参加过一个电器维修学习班，跟着一个老师傅学修家电（找工作也不容易）。老师傅手艺精湛，各种电器不管带有什么疑难杂症，摆弄一阵就修好了，当时佩服不得了。等老师傅手上没活了，少不了向他请教一翻。于是，我说出了一个疑问：电器各式各样，花样翻新，要把每一种电器的原理都研究透，得花多少时间？你是怎么做到的呢？老师傅告诉我：我根本就不懂什么原理，我只会拆解和安装，拆解之后把每一部分跟正常的去比对，发现有差异就换掉，于是就修好了。原来如此！