[Oberon] Stack overflow in ORB.OutType

Michael Schierl schierlm at gmx.de
Tue Jun 16 19:32:06 CEST 2020

Hello Tomas,

Am 16.06.2020 um 06:49 schrieb Tomas Kral:
>> Today I remembered that a few weeks ago I stumbled upon a stack
>> overflow in the RISC5 Oberon compiler
> Hi, running FPGA, how can I tell, stack overflow happens. Except for
> obvious locking the system?

If it is locking the system and you cannot BREAK back to the system, it
is quite a good chance that something overwrote your module space,
likely a stack overflow.

But sometimes stack overflows only overwrite parts of the module space,
and then they are hard to diagnose. For me, at least once a stack
overflow overwrote just enough code so that the system started to behave
strangely and corrupt the filesystem. So even after a hard reset the
system was no longer able to boot and I had to salvage files from the
disk image manually.

> What happens to the stack, does it grow into the heap, smashing it,
> any LEDs we get?

Sometimes you will also see rendering artifacts on screen, I am not sure
if the chance is high that you get any LEDs.

If you suspect a stack overflow, you can patch your compiler to check
for "almost stack overflow" on every procedure entry, and TRAP in case
there is one. My code at


implements just this, and uses the (otherwise unusd) TRAP 9 for that.

After patching your compiler, you need to recompile all code where you
suspect the stack overflow. (So in my case the compiler again). Then try
to reproduce the issue and watch out for TRAP 9.

I want to make clear that this modification has some runtime penalty, so
while you may want to use it when debugging, you probably do not want to
use this all the time. (In an emulator, I don't care much and mostly run
my "debug build" which has this and other modifications built-in).



More information about the Oberon mailing list