Oberon

Download

oberon@mailman3.inf.ethz.ch

April 2004

12 participants
21 discussions

Re (3): [Oberon] n-o trap analysis confuses me
by easlab＠absamail.co.za 01 Apr '04

01 Apr '04

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

1 0