[Oberon] n-o trap analysis confuses me

[easlab at absamail.co.za]

> es> A trap 7 shouldn't be a big problem BTW.
> 
Peter wrote:
> Sure enough, Googling 'site:oberon.ethz.ch "trap 7"'
> yields http://www.oberon.ethz.ch/native/WebTraps.html 
> which contains very nicely written instructions on 
> analysis of traps.  We're running out of excuses for 
> fixing some of the problems!
> 
The previous problem which I reported is/was that I suddenly had 
TRAP -14 for all
Desktops.OpenDoc "http://www*"

Well, I had a power-outage and a 'Windoof' aka reboot.
And after that no more problem.  But I've had this problem for months
between reboots.

My immediate [superficial] guess is that it is related to the heap 'load',
since I normally have a week or 2's work load between re-boots.

Using Compiler.Compile *\f
 on PC =  PC = 7583 &  5551 ,  [on a sytem which no longer traps]
based on:
 TRAP -14  NIL reference ( 00000014H ) (PC Native 11.10.2001)
 HTMLImages.ImgIcon  PC = 5551
 	key = 53
 	keyAttr = "IMGKey"
 HTMLImages.IMG  PC = 7583
 	C =  00000018H
 	E =  0044EB80H
 	P =  0014C7E0H
 	S =  000000A8H
 	alt = "Valid HTML 4.01!"
 	attr = ""
 	battr =  00000000H
 	border = 0
 	doc =  00000000H
led to confusion.

Examining the small PROCEDURE ImgIcon [below] led to a
first guess that C was not initialised, so I manually traced were it
was [to be] initialised. Although the trap-trace shows C as non-zero ?

 Here's the skelton as I see it [with 1,2,3,4 being the execution sequence]:-
{ pity you can't see in colour - don't you just love n-o ! }

	PROCEDURE IMG(VAR S: HTMLDocs.Scanner; on: BOOLEAN);
		VAR
.........
			C: Objects.CopyMsg;
		PROCEDURE ImgIcon(keyAttr: ARRAY OF CHAR; key: LONGINT);
		BEGIN
			doc := NIL;
			obj := Gadgets.FindPublicObj("Icons.Picture");
			Links.GetLink(obj, "Model", obj);
			C.id := Objects.shallow; Objects.Stamp(C);
3			C.dlink := NIL; C.obj := NIL; obj.handle(obj, C);<-- Compiler.Compile *\f			
			NEW(iCon); E.obj := iCon; iCon.entry := E;
			Rembrandt.NewP(iCon, C.obj(Pictures.Picture));
			icon := iCon; icon.handle := IconHandler;
			Attributes.SetInt(icon, keyAttr, key);
			Attributes.SetString(icon, "Cmd", "HTMLImages.LoadIMG")
		END ImgIcon;
1	BEGIN  <-- IMG
...
			IF ~HTMLDocs.imgs OR (doc = NIL) THEN
2				ImgIcon("IMGKey", ikey); Attributes.SetInt(icon, "
^^ calls the trapping proc
.....
4					Pictures.ReplConst(C.obj(Pictures.Picture), Display.BG, ..
^^ before variable C is *accessed* [never mind initialised] !!
.....
	END IMG;
------
It seems to me that C is not initialised in either of the 2 Procs.
 before it runs the trapping statement [in PROCEDURE ImgIcon].

BTW at this stage, I'm less worried about the trap-cause than debugging
the flaw(s) in MY logic.

It may be relevant that the same statement pattern as that calling the
trapping proc, is commented out further up in the calling proc: 
PROCEDURE IMG.    See:
				IF ~HTMLDocs.imgs OR (doc = NIL) THEN
					ImgIcon("IMGKey", ikey); Attributes.SetInt(icon, "OBJKey"...