gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Camm Maguire
Subject: [Gcl-devel] Re: STABLE, WINDOWS: read_fasd1() and alloc_relblock()
Date: 18 Apr 2004 17:48:49 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

Great work, as always, Mike!

Mike Thomas <address@hidden> writes:

> 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.
> 

OK, GETD resolves to getd which resolves to getc on the stream, which
is defined on Linux thus:

SYNOPSIS
       #include <stdio.h>

       int fgetc(FILE *stream);
       char *fgets(char *s, int size, FILE *stream);
       int getc(FILE *stream);
       int getchar(void);
       char *gets(char *s);
       int ungetc(int c, FILE *stream);

DESCRIPTION
       fgetc() reads the next character from stream  and  returns
       it  as  an  unsigned char cast to an int, or EOF on end of
       file or error.

       getc() is equivalent to fgetc()  except  that  it  may  be
       implemented  as  a  macro which evaluates stream more than
       once.


My guess is that getc is returning char on Windows, in which case we
have some serious work.  Can you please confirm?

BTW, if this is an issue (setq compiler::*default-system-p* t) should
be a workaround.  (Sidesteps the fasl, data is read in as fully
written out lisp code.  (setq compiler::*default-data-file* t) to
confirm). 

> 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?
> 

What settings are we talking about?  One of them apparently tries to
optimize the getc call.  I doubt the linker is implicated here --
please correct me if I'm missing something.

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

Pure legacy, left untouched under the general principle that I avoid
changing anything obviously explicitly inserted in the past unless I'm
sure it won't break something relying on it.

> 
> 
> 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 );
>        }
> 

More on this later.

Take care,

> 
> Cheers
> 
> Mike Thomas.
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]