[Oberon] PO2013 - Show Heap Blocks

Tomas Kral thomas.kral at email.cz
Wed Jun 24 19:16:40 CEST 2020


On Wed, 24 Jun 2020 17:15:03 +0100
Paul Reed <paulreed at paddedcell.com> wrote:

> Of course if your output routines are using the heap..

Yes, precisely that was it.

  PROCEDURE Lists*;
    VAR p, list0, list1, list2, list3: INTEGER;
  BEGIN
    p := S.ADR(Kernel.MemLim);
    S.GET(p+8, list0); (*256*) S.PUT(9FEF0H, list0);
    S.GET(p+12, list1); (*128*) S.PUT(9FEF0H+4, list1);
    S.GET(p+16, list2); (*64*) S.PUT(9FEF0H+8, list2);
    S.GET(p+20, list3); (*32*) S.PUT(9FEF0H+12, list3);
    (*Out.Hex(list3); Out.Hex(list2); Out.Hex(list1); Out.Hex(list0);
    Out.Ln*) (* <== use heap!!!*)
  END Lists;

I realised with Output uncommented, seeing different values for the same lists on olr at RPI and RISC, machines connected with rs232, the later running Oberon0 interpreter.

>> I deposit lists at free address 9FEF0H  
> Why is that free?  It's in the heap, isn't it?

Mine limits are 60000H .. 9FEF0H; 9FEF0H being last word on the heap.
Yes, I overwrite it with list0. Should better start at 9FEF4H.

> If you want, you can hook Kernel.New from your own trap handler, so
>that 
> you can do any heap checking on every allocation - it shouldn't take 
> long to track down what's causing the corruption.  But it may be
>enough 
> to check after each command executed, for example. 

Ah, user traps, that reminds me of ATARI-ST or Sinclair QL coding.


-- 
Tomas Kral <thomas.kral at email.cz>


More information about the Oberon mailing list