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的任务早跑了

关于“Utility中遇到Page Fault错误怎么办”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。