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