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

[Mike Thomas]

Hi all.

Mainly good news but still not out of the woods vis-a-vis gcc 3.3.3 and
binutils 2.15.90.  A lot of separate parts to this email.

Vadim, are you able to reproduce the results below using current CVS stable?
Note the combinations of gcc/binutils versions I am using, which I believe
are different to yours.



| >    2. whatever crashes remain when these fixes are tested on compiling
| > applications and the random tester (eg Maxima path troubles etc),
| >
|
| What is the status with gcc 3.3.3 and gcl/maxima, for example?

Using the Maxima 20040219 source package (both with and without
ignore-errors) and stable CVS GCL (which contains my fixes of last night):

1. GCL/gcc 3.3.1/binutils 2.14.90 builds Maxima and passes tests both with
and without ignore-errors - I haven't been able to replicate the
"ignore-errors" path mangling bug so that looks good.

2. GCL/gcc 3.3.3/binutils 2.15.90 still causes the Maxima crash.  It now
crashes consistently (which is also good news) while loading
"binary-gcl/specfn.o" so if we still have the fortitude and time we can
probably track it down.

The problem occurs in the Maxima source file "src/clmacs.lisp", function
"aset-by-cursor" called in "fillarray":


======================================================================
;    - Compiling module "special-functions"
;      - Loading binary file "binary-gcl/specfn.o"
Loading binary-gcl/specfn.o
Error in CONDITIONS::CLCS-LOAD [or a callee]: Caught fatal error [memory may
be
damaged]

Fast links are on: do (use-fast-links nil) for debugging
Broken at FILLARRAY.  Type :H for Help.
 1 (Continue) Retry loading file "binary-gcl/specfn.o".
 2 (Abort) Return to top level.
dbl:MAXIMA>>(si::use-fast-links nil)

NIL
dbl:MAXIMA>>1

Loading binary-gcl/specfn.o
Error in FILLARRAY [or a callee]: Caught fatal error [memory may be damaged]

Broken at CONDITIONS:INVOKE-DEBUGGER.  Type :H for Help.
 1 (Continue) Retry loading file "binary-gcl/specfn.o".
 2 (Abort) Return to top level.
dbl:MAXIMA>>:bt

#0   INVOKE-DEBUGGER
{datum=#<conditions::internal-simple-stream-error.0>,argume
nts=nil,loc2=#<condit...} [ihs=62]
#1   ERROR
{datum=conditions::internal-simple-stream-error,arguments=(:function-
name fillar...} [ihs=61]
#2   CLCS-UNIVERSAL-ERROR-HANDLER
{error-name=:error,correctable=nil,function-na
me=fillarray,continue-format-strin...} [ihs=60]
#3   ASET-BY-CURSOR {loc0=#(0.0 0.0 0.0
...),loc1=14.0,loc2=(15),loc3=15,loc4=0,
loc5=#<compiled-func...} [ihs=59]
#4   FILLARRAY {loc0=#(0.0 0.0 0.0 ...),loc1=(14.0 1.9350643000000001
0.16607303
300000001 ...)} [ihs=58]
#5   CLCS-LOAD {file=("binary-gcl/specfn.o"),args=nil,g2549=(nil
"binary-gcl/spe
cfn.o"),loc3=(#...} [ihs=57]
#6   FUNCALL {loc0=#<compiled-function
conditions::clcs-load>,loc1="binary-gcl/s
pecfn.o"} [ihs=56]
#7   FUNCALL {loc0=#<compiled-function
conditions::clcs-load>,loc1="binary-gcl/s
pecfn.o"} [ihs=55]
#8   LOAD-FILE-OPERATION {} [ihs=48]
#9   COMPILE-AND-LOAD-OPERATION {} [ihs=44]
#10   FUNCALL {loc0=make::compile-and-load-operation,loc1=#<FILE:
specfn>,loc2=:
new-source-and...} [ihs=43]
#11   FUNCALL {loc0=make::compile-and-load-operation,loc1=#<FILE:
specfn>,loc2=:
new-source-and...} [ihs=42]
#12   OPERATE-ON-COMPONENT {} [ihs=36]
#13   OPERATE-ON-COMPONENTS {} [ihs=31]
#14   OPERATE-ON-COMPONENT {} [ihs=25]
#15   OPERATE-ON-COMPONENTS {} [ihs=20]
#16   OPERATE-ON-COMPONENT {} [ihs=14]
#17   OPERATE-ON-SYSTEM {} [ihs=9]
#18   FUNCALL
{loc0=make:operate-on-system,loc1="maxima",loc2=:compile,loc3=:ver
bose,loc4=t,lo...} [ihs=8]
#19   FUNCALL
{loc0=make:operate-on-system,loc1="maxima",loc2=:compile,loc3=:ver
bose,loc4=t} [ihs=7]
#20   TOP-LEVEL {} [ihs=5]
#21   FUNCALL {loc0=#<compiled-function
system:top-level>,loc1=nil,loc2=0,loc3=0
,loc4=nil,loc5...} [ihs=4]
NIL
dbl:MAXIMA>>

========================================================================

Inserting some tracing stuff shows that the problem is with the ecase -  the
values used to switch and set on the first case branch all seem to calculate
and work correctly by themselves:



========================================================================

(defun aset-by-cursor (ar  val)
  (let ((curs  *acursor*))
    (declare (type (simple-array fixnum (11)) curs))
    (print curs)   ; Added By Mike
    (print *acursor*)   ; Added By Mike
    (print (aref curs 0))   ; Added By Mike
    (print (aref curs 1))   ; Added By Mike
    (setf (aref ar (aref curs 1)) val)   ; Added By Mike
    (print "hello")   ; Added By Mike
    (print ar)   ; Added By Mike
    (ecase (aref curs 0)
      (1 (setf (aref ar (aref curs 1)) val))
      (2 (setf (aref ar (aref curs 1) (aref curs 2)) val))
      (3 (setf (aref ar (aref curs 1) (aref curs 2) (aref curs 3)) val))
      (4 (setf (aref ar (aref curs 1) (aref curs 2) (aref curs 3)
                     (aref curs 4)) val))
      (5 (setf (aref ar (aref curs 1) (aref curs 2) (aref curs 3)
                     (aref curs 4) (aref curs 5)) val)))
    ;; set the index (`cursor') for the next call to ASET-BY-CURSOR
    (print "Past the case")   ; Added By Mike
    (print ar)    ; Added By Mike
    (sloop for j downfrom (aref curs 0)
       do (cond ((< (aref curs j) (aref curs (f+ 5 j)))
                 (setf (aref curs j) (f+  (aref curs j) 1))
                 (return-from aset-by-cursor t))
                (t (setf (aref curs j) 0)))
       (cond ((eql j 0) (return-from aset-by-cursor nil))))))

========================================================================


start address -T 10f38000 Finished loading binary-gcl/trgred.o

;    - Compiling module "special-functions"
;      - Loading binary file "binary-gcl/specfn.o"
Loading binary-gcl/specfn.o
  1> (FILLARRAY
         #(0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0)
         (14.0 1.9350643000000001 0.16607303300000001 0.0248793229
          0.0046863619600000005 0.0010016274999999999
          2.3200219600000001E-4 5.6817822700000005E-5
          1.4496300600000003E-5 3.8163294599999999E-6
          1.0299042599999999E-6 2.8357538499999994E-7
          7.9387055000000009E-8 2.2536705000000001E-8
          6.4743380000000008E-9))
    2> (SET-UP-CURSOR
           #(0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
             0.0))
      3> (ARRAY-DIMENSIONS
             #(0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
               0.0))
      <3 (ARRAY-DIMENSIONS (15))

6
1     <2 (SET-UP-CURSOR NIL)
    2> (ASET-BY-CURSOR
           #(0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
             0.0)
           14.0)

#(1 0 0 0 0 0 14 0 0 0 0)
#(1 0 0 0 0 0 14 0 0 0 0)
1
0
"hello"
#(14.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0)
Error in ASET-BY-CURSOR [or a callee]: Caught fatal error [memory may be
damaged
]

Fast links are on: do (use-fast-links nil) for debugging
Broken at SYSTEM::TRACE-CALL.  Type :H for Help.
 1 (Continue) Retry loading file "binary-gcl/specfn.o".
 2 (Abort) Return to top level.
dbl:MAXIMA>>================================================================
========






========================================================================

| > CFLAGS       = -O3 -fomit-frame-pointer -fno-zero-initialized-in-bss
| > -fno-inline-functions -mms-bitfields -Wall -fwritable-strings
| > -DVOL=volatile -fsigned-char $(PROCESSOR_FLAGS) -I$(GCLDIR)/o
| > FINAL_CFLAGS = -fno-zero-initialized-in-bss -mms-bitfields -Wall
| > -fwritable-strings -DVOL=volatile -fsigned-char $(PROCESSOR_FLAGS)
| > O3FLAGS      = -O3 -fomit-frame-pointer -fno-inline-functions
| > O2FLAGS      = -O -fno-inline-functions
| > OFLAG        =
| >
|
| Wonderful!!  What is OFLAG?  I just see *opt-three* and *opt-two* in
| the compiler package.


$ fgrep -r OFLAG o/
o/makefile:#OFLAG       = -O
o/makefile:     ${CC} $(OFLAGS) -o grab_defs  grab_defs.c
o/makefile-:#OFLAG      = -O
o/makefile-:    ${CC} $(OFLAG) -o grab_defs  grab_defs.c



| Take care, and thanks for your fantastic work here.  Am especially
| interested in the latest gcc/gcl/maxima combo results.

Likewise - I just needed to go to sleep last night and was hoping some
Windows user in the Western Hemisphere might be up to testing overnight.



| But perhaps
| I'm setting the prioritites incorrectly -- if there are bugs of the
| order of the getc issue you've discovered still in the gcc compiler,
| then perhaps it is too hasty to conclude that the crash of the above
| combination is gcl's fault.  Do you have a sense of the stability of
| gcc 3.3.3 on mingw in general?

Gcc 3.3.3 seems OK to me - I've been using it to build the Glasgow Haskell
Compiler over the past few weeks.


|  we should at least be set with gcc
| 3.3.3 with all optimzation turned off, no?

I'll need to check, this afternnon hopefully.


Cheers

Mike Thomas.