gcl-devel
[Top][All Lists]
Advanced

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

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


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

Greetings!

"Mike Thomas" <address@hidden> writes:

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

...

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

Fantastic!!  Was it the -fno-inline-functions or the getc redefine?
I'm guessing the former.  In fact, with the former, why do you need
the latter?

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

                       ^^^^^^^^^^^^^^^^^^^^^^^^

Indeed.  Any idea of why the inline function optimization produced
*irregular* crashes?

> "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":
> 

OK, my suggestion here would be to configure gcl with debugging, and
build maxima with --enable-gcl --enable-gcl-alt-link.  This will give
you an image fully addressable within gdb.  If the build doesn't
complete, as is likely, just link in the clmacs.o file with

(compiler::link (list "clmacs.o") "new_gcl")

and restart the problem command with new_gcl under gdb, adjusting the
command so as not to reload clmacs.o.

You might also want to just try the vanilla maxima build under gdb and
get a backtrace to the location within aset-by-cursor that causes the
crash. 

Separately, it appears from Vadim's email that I've been mistaken in
thinking gcc 3.3.3 was the latest official gcc on mingw, in which case
chasing down this problem now would be critical.  Is gcc 3.3.3 on
mingw only a 'candidate'?  If so, the bug is still important, but not
so crtitical as to further delay the release IMHO if the information
gleaned from the above steps reveals a time consuming job ahead of us.

Thanks again to both of you for your *fantastic* work here!

Take care,

> 
> ======================================================================
> ;    - 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.
> 
> 
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

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