Oberon/ETH Oberon/穩定性 - Wikibooks，開放世界中的開放書籍

此文件最初託管在 ETHZ。它仍然受 ETH 許可證的約束，並且位於 WayBack 檔案中。

ETH Oberon 系統穩定性

穩定性是 Oberon 的一個突出亮點。然而，存在一些方法會導致系統“不可恢復”地凍結，下面將討論這些方法。

錯誤地使用不安全的 SYSTEM 功能或低階模組（例如核心）的不安全介面。
當發生堆疊溢位時。原生 Oberon 和 Bluebottle 透過將堆疊區域的底部頁面留在虛擬記憶體中未對映來解決此問題。這會導致堆疊溢位時發生頁面錯誤。這很可靠，即使對於大型區域性變數也是如此，因為堆疊初始化是從上到下進行的。當在過程標題中將非常大的陣列作為值引數傳遞時，可能會發生堆疊溢位。增加堆疊大小（在最後討論）是一種解決方法，但最佳解決方案是使用 VAR 形式引數或指標。作為一個具體的例子，嘗試在你的 Oberon 系統上執行以下命令，看看它如何處理由遞迴 Trap 呼叫引起的堆疊溢位（警告：它可能會崩潰）
```
MODULE Temp; 
  PROCEDURE Trap*; 
  BEGIN 
    Trap 
  END Trap; 
END Temp. 
Temp.Trap
```
以下是針對四個 ETH Oberon 系統（最新版本）進行的測試結果
1. 原生 Oberon
```
TRAP -14  Stack overflow ( 00103FFCH ) (PC Native 20.08.2002) 
Temp.Trap  PC = 10 
Temp.Trap  PC = 15 
...
```
2. 面向 Bluebottle 的 Oberon
```
[1] TRAP -14 PL 3 stack overflow Aos 20.07.2002 
CS:=0000001B DS:=00000020 ES:=00000020 SS:=0000002B CR0=80040031 FPU=00000000 
EIP=00574012 ESI=00573F70 EDI=8427F694 ESP=84261000 CR2=84260FFC PID=00000001 
EAX=00898DC0 EBX=0057400F ECX=00000000 EDX=005A8FF8 CR3=02FFE000 LCK=00000000 
EBP=84261000 FS:=00000000 GS:=00000000 ERR=00000006 CR4=00000000 TMR=00027BCA 
EFLAGS: cPaZstIdo iopl3 {1..2, 6, 9, 12..13, 16} 
Process: 18 run 1 2 0057A1B0:AosCommands.Runner AosLocks.ReleasePreemption pc=859 {0, 28} 
Temp.Trap pc=10 
Temp.Trap pc=15 
Temp.Trap pc=15 
...
```
3. 執行在 Windows 2000 版本 5.0.2195 Service Pack 2 上的面向 Windows 的 ETH PlugIn Oberon（14.5.2001）
```
TRAP stack overflow in thread Oberon.Loop 
Temp.Trap  PC = 7 
Temp.Trap  PC = 15 
Temp.Trap  PC = 15
```
4. 面向 Linux x86 的 Oberon 崩潰（終止 Oberon 程序）。此錯誤由 Günter Feldmann 分析。他發現沒有辦法處理由 Linux 中的堆疊溢位引起的段錯誤。在他所知的其他 Unix 版本中，堆疊溢位處理不是問題，因為它們支援用於訊號（陷阱）處理的備用堆疊。在 Oberon 的 Solaris 埠中，Temp.Trap 會產生兩個段錯誤陷阱。第二個（遞迴）陷阱檢視包含一條通知，告知使用者第一個陷阱可能是由堆疊溢位引起的。當他上次在 Linux（核心 2.2、x、glibc 2.2.1）中尋找備用訊號堆疊時，他最終找到了“signalstack”過程。但是呼叫此過程會導致程式崩潰。他希望在不久的將來訊號堆疊也能在 Linux 中工作。
堆疊大小 - 預設大小以及如何調整它
- 原生 Oberon：使用配置字串“StackSize”指定為堆疊分配多少位元組。預設值為 131072，即 128K。
- PlugIn Oberon：預設大小為 1MB。提供兩種調整它的方法（經過有效測試）
  1. 為執行關鍵程式碼的執行緒分配更多空間：在本例中為 Oberon 迴圈。在過程 Oberon.Loop 中，在 Threads.Start 呼叫中指定堆疊大小（以位元組為單位）。這種方法的缺點是，即使沒有（立即）使用，也會立即分配堆疊空間。
  2. 為 Oberon 程序的所有執行緒分配更多空間。在檔案 Win32.Oberon.Link 中，搜尋 HEAPSIZE 行，並在其後新增一行 STACKSIZE，其中包含適當的大小。
  在這兩種情況下，oberon.exe 都必須使用 PELinker.Link Win32.Oberon.Link ~ 重新連結（Oberon.exe 是隱式目標）。對於堆疊大小 <= 1 MB，將大小調整為 4096（頁面大小）的倍數，而超過 1 MB 則調整為 1048576（1 MB）的倍數。
  面向實現者的說明
  - PELinker 是開發人員包的一部分，必須安裝該包（參見 Packages.Tool）。
  - 只要模組 Oberon 的鍵沒有更改，重新連結新的 Oberon.exe 就足夠了。不要忘記將它複製到正確的位置。
  - 將舊的 Oberon.exe 儲存在一個子目錄（例如 /Obj）中，作為新版本失敗時的備份。
- Bluebottle（未測試）：在 AosMemory.Mod 中，調整 MaxUserStackSize 的值，編譯模組並重新連結它。預設值為 128K，但實際上大小為 124 KB，因為有一些空間被保留。
解除安裝一個模組，而其中一些過程變數引用仍然存在。視覺小工具的情況是這種現象的常見表現形式，可以用以下操作序列來證明：將插入符設定在檢視器中
執行 Gadgets.Insert BasicGadgets.NewButton ~
執行 System.Free BasicGadgets ~ 解釋：按鈕的處理程式被“竊取”了。在釋放一個模組時，Oberon 會檢查是否還有其他模組依賴於該模組，但它目前無法檢查是否有過程變數引用仍然存在（例如，引用視覺小工具的處理程式）。解決方法：不要在模組的物件仍然顯示時執行 System.Free，因為處理程式會在每次傳送 Display.Broadcast（或更新訊息）時被呼叫（當開啟新的檢視器（例如 TRAP 檢視器）時就是這樣）。解決方案：目標是使系統優雅地捕獲並不會崩潰。解決問題的一種方法是為每個模組設定一個終止處理程式。在大多數情況下這可能是真的，例如，如果您安裝了一個任務，或一些其他可以再次解除安裝的回撥。對於視覺小工具來說，這很困難，因為小工具除了在顯示空間中（按設計）以外，沒有連結到其他任何地方。即使向模組的小工具廣播“移除自身”訊息，也不一定總是有效，因為小工具可能在覆蓋的軌道中。此情況在原生 Oberon 中得到了正確的處理。務實的解決方案是
1. 在可能的情況下，模組終止處理程式（使用 Modules.InstallTermHandler 安裝）進行清理，以避免出現此問題。
2. 當框架處理程式捕獲時，框架將被關閉。這避免了遞迴捕獲和堆疊溢位，從而避免了系統崩潰。這段程式碼有點像駭客，但它似乎非常有效。它在 Viewers.Broadcast、Viewers.Close 和 System.Trap 中實現。在某些情況下，它會產生誤報，例如，有時當與小工具連結的命令捕獲時，包含該小工具的（無辜的）框架會被關閉。System.Recall 可用於將其呼叫回來。
當遇到“磁碟已滿”情況時 - 參見分割槽大小注意事項。
當 Oberon.Text 被破壞時，Oberon 啟動可能會突然結束。這種情況可能是由於在編輯 Oberon.Text 時輸入錯誤造成的。要從這種情況中恢復，必須編輯託管已損壞 Oberon.Text 的分割槽，方法是從另一個 Oberon 系統掛載檔案系統。另一個系統可以駐留在同一臺機器上、Oberon-0 啟動軟盤上或 CD-ROM 上。特別注意文字中用於巢狀部分的未匹配的“{”和“}”括號。Bluebottle 還包含一個 AosConfig.XML 檔案，該檔案指導啟動過程，並且它必須在語法上格式正確。一個小錯誤可能會導致啟動失敗。為了提高系統穩定性，系統準備自動切換到一個據稱完好無損的備用檔案 Save.AosConfig.XML，從而為使用者提供修復 AosConfig.XML 中錯誤的可能性。如果備用檔案已損壞，則必須應用與原生 Oberon 中描述的相同解決方案。這兩個檔案在發行版中是相同的。