[Oberon] Trap in storing a FAT file.

[eas-lab at absamail.co.za]

Peter E. wrote:
> On one pc there is a trap in half of all attempts to
> store a FAT file.  I've never used a trap report to chase 
> down a bug and can use a little guidance.  Can anyone
> tell me where to begin with analysing this report.

TRAP -14  NIL reference ( 00000000H ) (PC Native 05.01.2003)
OFSFATVolumes.AssignDirectoryEntry  PC = 22443  <-- last proc called
c =  00000000H = DirCache
dc =  00000000H = DirCache
direntry =  00000010H  = x
dummy = 0
num = 0
p =  003976E0H
pos = 0
res = 0  = x
vol =  001B5700H  = x
OFSFATVolumes.WriteDirectoryEntry  PC = 24169 <-- 2nd last proc called
@dim = 2048
chksum =  00000000X
cluster = 0
d = 0
dirCache =  00000000H
direntry =  00000010H =y
dummy = 0
idx = 0
k = 0
n = 0
pos = 0
res = 0 =y
t = 0
unicode = 47, 75, 69, 82, 77, 73, 84, 47 ...
vol =  001B5700H =y
OFSFATFiles.Rename  PC = 2781 <-- 3rd last proc called
----------
We see that WriteDirectoryEntry calls AssignDirectoryEntry with 3 args,
marked "=y" (and "= x") . The last 2 are VAR-pars and have not yet been
changed , which could tell how far AssignDirectoryEntry has progressed
before trapping.  { This might not be true if the compiler 'transforms'
the sequence of statement execution drastically from the apparent 
sequence as suggested by the source - I don't know how this compiler 
works }.

From: c =  00000000H , p =  003976E0H ,
my attention is drawn to this loop:-

	p := NIL; c := vol.dirCache;
	WHILE (c.type # dcSentinel)  & ((c.type # dcFree) OR 
       (c.entry.dirInfo.num < direntry.dirInfo.num)) 
    DO p := c; c := c.next END;

where the WHILE terminating condition is expected to occur
 before the linked-list finds it's tail at c.next = NIL.

I'm guessing that it does NOT !
I'm guessing that your machine is testing (which was not done before) 
that  c.next = NIL occurs before the WHILE terminating condition is 
satisfied.

Also looking at some of the local variables like:
 dummy = 0 , pos = 0
shows that they were not yet changed, before the trap.
{ Apparently n-o leaves uninitialised varaibles as zero [usually ?]}

My source code is from 2001, and has 
CONST
	Trace = FALSE;
	Detail = Trace & FALSE;
...
	IF Detail THEN
		Kernel.WriteString("   found at cluster "); Ker...etc.

Is this degugging stuff not still in your version ?

Of course you know about:
Compiler.Compile *\f
	f	find error position (select PC line in Trap viewer)

-- Chris Glur 

This is perhaps another example of problems be found by USERS
of n-o vs. theoretical playing with it.