Re (3): [Oberon] n-o trap analysis confuses me

easlab at absamail.co.za easlab at absamail.co.za
Thu Apr 1 06:27:52 CEST 2004


Edgar wrote:-
> So C itself doesn't need any initialisation. There is only an error if
> a field of C is read before write. Any argument for that ?

Yes: my underdstading of 'computing english' is that "initialise" means "the
first write to a varaible [within a context]; eg. the 'initilisation of a loop
counter'.  Searching Oberon.Report.Text for "nitiali" yield one find only:
]  All pointer variables inherit the extension relation of the basetype PTR and 
] are initialized to NIL.
Which is exactly the meaning I attribute to "initialise" and is perfectly
applicable to the point I raised: "please show mw where C.* was written
before it was read ? "
Apparently you are refering to the [lower level] implementation of storage
for the variable ?   Which of course also is a type of initialising.

BTW, on closer inspection of the 2 critical lines:
			C.id := Objects.shallow; Objects.Stamp(C); <-- var-par
			C.dlink := NIL; C.obj := NIL; obj.handle(obj, C);
I NOW don't see where I though there was a read before write/initialise ?!

> So my guess is:
> - The problem was that NEW(iCon) failed because the memory on the heap was
>   fragmented and there wasn't any continous space big enough left.
> - Fragmentation happens with time and if you open more and more viewers
>   over time this happens.
> - The Oberon garbage collector collects garbage but can't defragment the 
> heap
>   AFAIK.
> - So after a reboot this problem is obviously gone because you have an
>   unfragmented heap now.
> Just a guess but matches the facts I know.
> 
Yes, thas's the same theory which I was selling [with fewer words] 
some posts ago.  And I was about to reject it since I've  been 
operating intensively for many days now without the Trap re-appearing.

Happily the trap is now back:-
TRAP -14  NIL reference ( 00000014H ) (PC Native 11.10.2001)
HTMLImages.ImgIcon  PC = 5551
	key = 2040
	keyAttr = "IMGKey"
HTMLImages.IMG  PC = 7583
---
there's nothing worse than a fault that hides when you want
to uncover it's cause !

BTW, I predict that this Trap-cause still exists in the latest versions,
and descendants of n-o ?

== Chris Glur



More information about the Oberon mailing list