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 中描述的相同解决方案。这两个文件在发行版中是相同的。