[Ecls-list] Release ahead, report problems

[Andy Hefner]

On Mon, Feb 8, 2010 at 3:11 PM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> Andy, does this interruption happen also with a version from CVS?

Yes.

I doubt it will shed much light on things, but here's the output from
the ECL internal error:

;;; Internal error: in file math.lisp, position 842 and top form
;;;   (DEFUN PI/X (X) ...)
;;; (NIL NIL) is not of type FUNCTION.

PI/X is an uninteresting one-liner, declaimed inline, and with a
declaimed ftype. The error moves around when I modify the file, as if
memory corruption is occurring. For instance, adding an extra DEFUN
earlier in the file, the error becomes:

;;; Internal error: in file math.lisp, position 897 and top form
;;;   (DEFUN PI/X (X) ...)
;;; ((#<foreign :POINTER-VOID 00000000> . SI:CLOSE-WINDOWS-HANDLE)) is
not of type FUNCTION.

Or, commenting out a large preceding DECLAIM form, the error moves to
two functions deeper into the file:

;;; Internal error: in file math.lisp, position 918 and top form
;;;   (DEFUN +MOD3 (X Y) ...)
;;; (0 3) is not of type FUNCTION.

I've also seen other random errors, like complaints about GOing to a
nonexistent tagbody. Interestingly, it's always this same file
(math.lisp) where these errors occur. Wondering if a previous file in
the build was screwing things up, I moved math.lisp around in the
build order, which changed the errors, but they still occurred in that
file. I haven't yet been able to reproduce this by compiling the file
by hand outside of my app's build script, and was initially puzzled
that this still occurs with math.lisp at the top of the build order as
the first lisp file compiled. I've realized the environments aren't
identical between the two build attempts in this case, because on the
first (failed) attempt, several C files are compiled with compiler-cc
before moving on to the lisp files.


As for the GCC error, I guess there isn't much you can do about that,
but here it is:

;;; Note: Creating tag: "_eclemuctO6_Yg2zgAz" for #P"c:/g1/src/gamebar.o"
;;; Note: Invoking external command:
;;;   gcc "-Ic:/msys/1.0/local"  -g -O2   -D_THREAD_SAFE -Dmingw32
-Ic:/MinGW/include/freetype2 -DGLEW_STATIC=1 -Isrc/gl
ew -std=c99  -w -c "c:/g1/obj/gamebar.c" -o "
c:/g1/src/gamebar.o"c:/g1/obj/gamebar.c:761: internal compiler error:
in build_function_type_skip_args, at tree.c:5954
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

I looked into this a little. gamebar.c:761 is the last non-blank line
in the file, the closing brace of whatever it is you call the function
that links the definitions from that file into the environment
(calling install-method, etc.) I compared the generated gamebar.c from
the first attempt (where GCC crashes) from the gamebar.c which GCC
successfully compiles. I noticed that there seemed to be a difference
in debug levels, which presumably leak from earlier files in the build
on the first compilation attempt. The failing version of the file has
additional debug info (ecl_descriptors for local variables) which are
missing from the successfully compiled version. On the other hand, if
it's reasonable to think that the GCC crash is something local to the
aforementioned init function, the only difference between the two
versions of that specific function is that the crashy one goes through
ecl_function_dispatch while the good version calls clos_ensure_class
and clos_install_method directly.

What I don't get is that everything should be at (debug 3) and (speed
0), with only a difference in safety. The build script proclaims
(optimize (debug 3) (safety 3) (speed 0) (space 0)) before compiling
any source files. Several source files have a (declaim (optimize
(debug 3) (safety 2) (speed 0) (space 0)) at the top, but most have no
optimize level set. Removing all the optimize declaims made the error
go away. Perhaps coincidentally, removing the proclaim (or changing it
to a declaim) in the build script also makes the math.lisp internal
error go away. Do declaimed optimize levels in one file persist in
subsequent files?