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

[Guenter Feldmann]

|>   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 versi
ons):
|>   
|>   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
|>   > [...]
|>   > 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.

I found no way to handle a segmentation violation caused by stack overflow
in Linux. In all real Unix versionas I know of, stack overflow handling is
not a problem as they support an alternate stack for signal(trap) handling.
In the Solaris ports of Oberon Temp.Trap yields two sementation violation
traps. The second (recursive) trap view contains a notice which informs the
user that the first trap was probably caused by stack overflow.

When I looked for the alternate signal stack in Linux last time 
(Kernel 2.2,x, glibc 2.2.1) I finally found the procedure sigaltstack. But
calling this procedure crashed the program. I hope that in the near future
sigaltstack will work in Linux too.

-- Guenter

--
Guenter Feldmann		EMail:  G.Feldmann at informatik.Uni-Bremen.de
FB 3, Informatik
Univ. Bremen