[Oberon] PO2013 - Infrequent TRAPs

[Chris Burrows]

Which PO2013 Disk image did you start with? (source and date)

Can you describe any sequence of steps, 

1. from initial boot time and
2. on a system which uses all the latest code from the www.projectoberon.com
site and
3. which doesn't include any of your modifications to the latest code

that reliably reproduces any of these problems? 

Regards,
Chris Burrows
CFB Software
http://www.astrobe.com

> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of Tomas
> Kral
> Sent: Sunday, 14 June 2020 12:42 AM
> To: Oberon at lists.inf.ethz.ch
> Subject: [Oberon] PO2013 - Infrequent TRAPs
> 
> Hi,
> 
> I know, this has been my on-and-off topic, here it is again.
> I keep record of traps I occasionally got, when working on new modules.
> 
> [1] When compiling does not finish
> LED=00100001
> LED(21H) ==> Oberon.GC mark does not pass
> 
> [2] When unloading fails
> LED=00100111
> LED(27H) ==> Oberon.GC scan does not pass
> 
> [3] When executing commands, e.g. ShowModules Position 8280 TRAP1 in
> Modules REPEAT s[k] := ch; (* <== array index *)
> 
> [4] When loading a file
> Position 6656 TRAP4 in Files
> WHILE (buf.apos # pos) (* <== buf is NIL *)
> 
> I do quite a bit of unloading, before I get things done, Is well possible
> then I smash the heap somehow?
> 
> I am surprised that on some rare occasions I even got [1] on freshly
booted
> system, and the first thing was to recompile a module.
> 
> I have experimented with ORB object allocation, class, exno, lev: as BYTEs
> vs INTEGERs.
> 
> With INTEGERs, [1] appears less frequent, than BYTEs, but that's only an
> observation, is most likely not the reason.
> 
> --
> Tomas Kral <thomas.kral at email.cz>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon