In certain cases, the Oberon system crashes when a smaller record allocation (<= 128 bytes) cannot be fulfilled anymore. The expected behavior is that the system just returns a NIL pointer p when a NEW(p) call fails. This error was found and reported by Jörg Kollmann.
On a more detailed level, the following happens:
- Situations exist where the heap has no free large blocks (the n*256 blocks) anymore.
- When being in such a situation, repeatedly calling NEW() with sizes of 32/64/128 will eventually cause the 256-allocator to be called. It will return 0 (NIL) to the 128-allocator, which may (depending on the original request) pass on 0 to the 64 and and 32 byte allocators.
- System memory corruption occurs because the 128/64/32 allocators do not check for 0 and initialize split-off half-size free blocks, thereby writing in low addresses (32.. 64.. 128..).
- the resulting crash may occur immediately, or much later after correctly returning a NIL pointer.
An update of the Kernel module is available to remove the problem. (the next release of Oberon Workstation will include this, or a similar solution).
You can simply replace the old .Mod and .rsc files in your Oberon directory(s), or compile the module yourself.
If you use a different Oberon-07 implementation (FPGA/Windows/Linux etc.) You should only copy the procedures
GetBlock128, GetBlock64 and GetBlock32 into your Kernel.Mod file.
Update of Directory.Mod
The example application Directory.Mod which converts Oberon Text files into their stripped (no "looks" attributes) version has a small update. In the update,
Oberon.Collect() is now called with zero, ensuring soonest garbage collection after each task invocations ends.