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錯誤怎么辦”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。