Re (2): [Oberon] ETH Oberon/Gadgets: System Freeze in unloading

[muller at inf.ethz.ch]

"Patrick, Dr. med. Hunziker" <PHunziker at uhbs.ch> wrote:
> ETH PlugIn Oberon for WindowsTM / Win32 2.4 (15.12.2000)

You are using a quite old version of Windows Oberon.  This problem
seems to have been fixed in later versions (see below).

> However, in several years of working with Oberon, I have only found 
> three ways to produce C-like system freezes
> apart from using the unsafe SYSTEM feature:
> A) calling C programs from within Oberon
> B) passing very large arrays as value parameters in procedure headings
> C) unloading modules whereby some visual gadget is still hanging 
> around somewhere, as mentioned above.  
> I feel system stability is a prominent one of the many highlights of 
> Oberon, so the points B and C hurt the more...

BTW Both B and C are addressed in Native Oberon, and A is not relevant there.

The problem in B is a stack overflow.  For example, try the following
command on your Oberon system to see how it handles stack overflow
(warning: it may crash):

MODULE Temp;
  PROCEDURE Trap*;
  BEGIN
    Trap
  END Trap;
END Temp.
Temp.Trap

Here are the results on the four ETH Oberon systems I tested (latest versions):

1. Native Oberon:
> TRAP -14  Stack overflow ( 00103FFCH ) (PC Native 20.08.2002)
> Temp.Trap  PC = 10
> Temp.Trap  PC = 15
> ...

2. Oberon for Aos:
> [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
> ...

3. ETH PlugIn Oberon for Windows (14.5.2001):
> TRAP stack overflow in thread Oberon.Loop
> 
> Temp.Trap  PC = 7
> Temp.Trap  PC = 15
> Temp.Trap  PC = 15
(this was running on Windows 2000 Version 5.0.2195 Service Pack 2)

4. Oberon for Linux x86 crashes (terminates the Oberon process).
I suspect this is simply a bug that can probably be fixed by Günter.

So problem B is solved already in the latest versions of Native Oberon 
and Windows Oberon.

Native Oberon and Aos solve this problem by leaving the bottom page 
of the stack area in virtual memory unmapped.  This causes a page 
fault when the stack overflows.  This is reliable, even for large 
local variables, since stack clearing is done from top to bottom 
using PUSH instructions.

Felix Friedrich <friedrich at gsf.de> wrote:
> Do you see a solution for C) ?

Native Oberon solves this problem, but AFAIK the solution was not
ported correctly to any other ETH Oberon system.

Felix Friedrich <friedrich at gsf.de> wrote:
> So the "solution" is: Do not System.Free a Module when its Objects are 
> still displayed, since they are not deallocated and the Handler is called 
> any time a Display.Broadcast (or update message) is sent (which is the case 
> when new Viewers like a Trap-View are opened.)

True, but if this happens we would like the system to trap gracefully,
and not crash.

Frank van Riet <Fvanriet at spescom.com> wrote:
> I believe the best way to solve the problem is to have a termination handler
> for each module.

True in most cases, e.g. if you have installed a task, or some other upcall
that can be uninstalled again.  In the case of visual gadgets, this is 
difficult, because the gadgets are not linked anywhere except in the 
display space (by design).  Even broadcasting a "remove yourself" 
message to the gadgets of the module will not always work, since the
gadget may be in a covered track.

Felix Friedrich <friedrich at gsf.de> wrote:
> On the other hand: I want to be the boss of my computer: I say System.Free 
> and I want the system to execute System.Free unless there are very specific 
> reasons not to do, like depending modules. I do not accept depending 
> objects as a reason since there seems to be no way to check if displayed 
> objects depend on any of the freed objects. )

I agree.  See below.

"Douglas G. Danforth" <danforth at greenwoodfarm.com> wrote:
> I would think the simplest solution would be to tie a visual 
> gadget to the module that created it.  Freeing of that module
> could then not occur as long as an instance of the gadget
> occured anywhere.

I remember reading somewhere (perhaps in something written by
M. Hof?) that some version of Linz's Oberon used their metaprogramming 
facilities to trace procedure variables and refuse to Free a module 
that is still referenced by a procedure variable.  They found it was 
a nuisance in practice.

The pragmatic solution to this problem in Native Oberon is:

1. Where possible, the module termination handler (installed with
Modules.InstallTermHandler) cleans up so that this problem does not occur.

2. When a frame handler traps, the frame is closed.  This avoids
recursive traps and stack overflows, which avoids system crashes.

The code for this is a bit of a hack, but it seems very effective.
It is implemented in Viewers.Broadcast, Viewers.Close and System.Trap.

In some cases it produces false positives, e.g., sometimes when a 
command linked to a gadget traps, the (innocent) frame containing 
the gadget is closed.  System.Recall can be used to recall it.

-- Pieter

P.S. When posting to oberon at inf, please use the email address that
you have subscribed, otherwise your posting is delayed until
manually approved by the administrator.  There is also a chance
that it gets mistaken for spam and deleted.

--
Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich
Native Oberon OS: http://www.oberon.ethz.ch/native/