Utility之Page Fault
Utility之Page Fault
很多人在X86的设备里执行VxWorks应用时，遇到过Page Fault错误。
这是X86 CPU的14号异常，指的是访问存储器的指令发生了页异常。
我以往的经验，这样情况多是地址错误引起的，而主要的地址错误就是栈溢出(或者叫栈越界)。我们写个例子模拟一下
在X86的VxWorks里启个任务执行它
可以看到任务t1的栈用的是默认值20000，但是代码中有个0x10001的数组sss，很明显栈不够用的。sss的结束地址0x172a9db还在任务栈内，但sss的起始地址0x171a9db已经超出了栈的范围[0x172aaa0,0x1725c80]。这时候再按一下键盘，就会出现刚刚的Page Fault了。
在实际工作中，给我们带来困扰的一般是这个任务(例如t1)已经退出了，因此出现Page Fault时，用i或checkStack命令已经找不到罪魁祸首了。
在《Task之系统任务》里提到过，可以在任务的最后位置添加一个taskSuspend(0)，把它挂起来。然后就可以用checkStack了
这样就能抓到现形了。
在VxWorks里有个组件，INCLUDE_PROTECT_TASK_STACK，用于保护栈的溢出。我们加上它来试一试
这时候再执行同样的程序后，VxWorks立刻重启了，添加了taskSuspend(0)也没用。在bootrom里，用e命令可以看到重启的原因
有了这个保护，再有越界就会立刻重启，不会把危险推后。因为有的时候越界，并不会立刻暴露问题。
既然说到了越界，还有一些比较常见的情况，例如数组越界、指针越界。看个例子
数组a2只有一个成员a2[0]，但赋值时，写入了两个成员a2[0]和a2[1]。
可以看到，写a2[1]时，实际操作的a3的地址
如果当前文件中，a2[]后面没有声明其它变量，那被操作的地址就很隐蔽了。我们再试一下
重启VxWorks，我们先看看a2后面是谁
哦，有个变量叫runtimeName，人家的值是0x595239
然后执行程序，再看看它的值
后面那个变量runtimeName被修改了…
只要这个VxWorks系统没有关机，在若干年之后，就可能有个任务访问变量runtimeName，那时就会出问题，但那个时候，它只能背锅了… 执行aaa的任务早跑了
这正是：
地址越界危害大，莫名其妙背锅侠。
纵有工具帮定位，若想根除查代码。
本文分享自 这里只有VxWorks 微信公众号，前往查看
如有侵权，请联系 cloudcommunity@tencent.com 删除。
本文参与?腾讯云自媒体同步曝光计划? ，欢迎热爱写作的你一起参与！