[Oberon] PO2013 - Show Heap Blocks

Joerg joerg.straube at iaeth.ch
Wed Jun 24 10:19:54 CEST 2020


The heap has two different blocks
a) free blocks
b) blocks allocated by NEW

- list0 to list3 cover a).
- the garbage collector tries to catch all b).

As Paul said corruptions might occur with low level programming (SYSTEM) or when you used more heap memory than available and didn’t check for illegal pointers. Unfortunately, the published Kernel.Mod on projectoberon.com behaves badly on low memory, although we sent corrections to NW already.

Corruptions can have two flavours:
- either list0 .. list3 do not list all empty blocks correctly.
- The garbage collector can not traverse the allocated blocks correctly.

br
Jörg

> Am 24.06.2020 um 10:45 schrieb Paul Reed <paulreed at paddedcell.com>:
> 
> Hi Tomas,
> 
>> Apologies for the confusion, until now I confused only myself :-)
> 
> Don't worry.  But since it seems difficult to give complete or even correct information let's take a step back:
> 
> 1. The garbage collector runs when there is an empty stack, marking as used all memory found recursively starting only from pointers in each module's static data area.  Everything else is marked as free and placed on one of four free lists.
> 
> 2. The language ensures that memory cannot be corrupted in normal operation.
> 
> 3. Code which uses SYSTEM can corrupt memory if not written correctly.
> 
> 4. The already-observed corruption can be detected by walking each free list and doing a sanity check on the pointers (will fail with the data you have shown us).
> 
> Improving slightly the tools you now have, you should be able to zero in on when the corruption occurs, assuming 1. and 2. are not violated.
> 
> HTH,
> Paul
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon



More information about the Oberon mailing list