[Gcl-devel] STABLE, WINDOWS: read_fasd1() and alloc_relblock()

[Mike Thomas]

Hi all.


PART 1: read_fasd()

I happened on a combination of gcc optimisation flags which gave a 
repeatable hang on Windows in read_fasd1 (o/fasdump.c) while loading 
ansi-tests/rt.o.

It turns out that the local variable "leng" in that function declared as 
 "int" receives an erroneous result from "getc()" via the GETD macro 
while reading the fasd data appended at the end of "rt.o":

      case DP(d_short_string:)
        fprintf ( stderr, "rf1 d_short_string, byte i = %x\n", i );
        leng=GETD("leng=%d");
        fprintf ( stderr, "rf1 leng = %d\n", leng );
        leng = LENGTH(i,leng);
        fprintf ( stderr, "rf1 Before READ_STRING, leng = %d\n", leng );
        READ_STRING(leng,loc);
        fprintf ( stderr, "rf1 After READ_STRING\n" );
        return;

The erroneous result is -122 which really should be 134 (134 + 122 = 
256).  Redeclaring "leng" as "unsigned char" fixes that immediate 
problem but a crash occurs later anyway so presumably there are other 
places where such problems may be occurring.

I suppose that this could be some interaction between the mixed 
optimisation settings and the "-fsigned-char" compiler flag and possibly 
 even the GCL custom linker.  Perhaps the C linker would normally do 
stuff to help optimise across module boundaries and seamlessly connect 
functions which have been optimised differently which our linker doesn't?

Also, why do we use "-fsigned-char"?



PART 2: alloc_relblock()

The reason the above negative number causes a hang is that READ_STRING 
ultimately calls alloc_relblock() with a negative argument.  In 
diagnosing that problem however, I noticed that alloc_relblock() is 
being called repeatedly with the argument 0.

Camm, if you add these lines to the start of the function do you get 
similar results on Linux?

         if ( n <= 0) {
	   fprintf ( stderr, "WARNING: alloc_relblock allocating bad number of 
bytes %d\n", n );
         }


Cheers

Mike Thomas.