RE: [Gcl-devel] Windows - Instability in universe.lsp

[Mike Thomas]

Hi Camm.

Thanks for the reply, especially the helpful explanation.

| Don't suppose it would be possible to check just the cygwin compiler
| without doing a lot of work?  I.e. are the dll's used inextricably
| tied up with the compiler used?

The Cygwin DLL emulates Unix functionality but other than that both Cygwin
and MinGW32 use the same system DLL's.  The Windows specific code is all
going to be the same whether I build with Cygwin or MinGW32.

I'm drawing a sharp personal boundary here because I really don't want to go
down the route of mixing Cygwin and GCL; I just do not have the time and if
I wanted to write/use software that was Unix compatible/look and feel I
would rather just install Linux.  At least then it would then run quickly.
Without wishing to knock Cygwin too hard, because it does do some things
well, Cygwin makes software slow and brings with it a slew of problems and
bugs of it's own.

On the one hand, my attitude to this may seem illogical as I understand your
hope that this might help with debugging by means of comparison, but it will
require several hours of  debugging/rebuilding time assuming all actually
goes well.  I also understand your concern that we may be pushing away
potential Windows developers who want to use Cygwin GCL exclusively, however
my experience so far is that lots of people want to use Windows GCL or it's
client software, but very few are able to participate in the programming -
undoubtedly for perfectly valid reasons.  I'm also sure that sooner or later
supply will meet demand (whichever is more powerful).

On the other hand, GCL is seriously eroding my other spare time projects and
I am feeling quite toey about that!!  Additionally I'm going to have severe
access problems to my computer at home for a few weeks as my wife wants to
type in a book she has been writing.


| >
| > | Diff finished at Tue Mar 30 19:35:26
| > |
| > |    Perhaps you can report the output of this test and/or investigate
| > |    what is going on?  Perhaps you can also run with --enable-debug or
| > |    equivalently only -O0?
| >
| > I'm pleased to report that with the stable source updated this
| morning there
| > are now only 305 errors and that the particular test you
| mentioned passes.
| > I'll try again this evening with my other computer and see how
| we go there
| > but I'm expecting everything to match.
| >
|
| Great!  There are quite a few compiler options, of course, which are
| enabled in groups by the -O options.  Pinning down which option causes
| the 306th test to fail might be useful at some point.  Likewise if the
| 306th test can be made to fail in isolation.  I.e. (load
| "gclload1.lsp")(load "file containing failing 306th
| test.lsp")(rt:do-tests).  If so, then we can (disassemble...) the
| function definition for the failing test and try to get a simple test
| case.

Sadly my expectation was false and changing the optimisation to nothing at
all did not make the 306th failure go away.

| In general, though, I'm quite happy to proceed to 2.6.2 with -O0 on
| mingw if it continues to prove stable, i.e. fixes both ansi issues,
| and both maxima issues, particularly compiling maxima with the latest
| gcc.  For some as yet only partially understood reason, we are using
| -O0 on hppa too.

Maxima built and passed all tests by the way - I have yet to build a CLtL1
compiler and try ACL2.

| >
| > | 4) Re random tester -- I will endeavor to backport the minimal set of
| > |    files to run this against stable, as I feel it is an important
| > |    measure of GCL quality.  Will followup with Paul about this
| > |    separately.
| >
| > This falls in the category of thinking too hard close to the
| deadline - I
| > might be too scared to run the random tester!
| >
|
| Fear not -- my guess is that you'll be in good shape with -O0.

OK -O0 is equivalent to no optimisation according to the gcc manual by the
way.  I'm still gibbering.

I'm also going to try -Os to see what affect that has on performance and
functionality.


|
| >
| > | 5) Re any possible further debugging efforts -- I think we should
| > |    stick with stable until release
| >
| > Done.
| >
| >
| >
| > | 6) Re appearance of C stack in gdb as a sign of error -- this can
| > |    indicate an error, or it can indicate an issue with gdb, so it is
| > |    not a completely reliable test.  This having been said, I'm
| > |    including below the results of my gdb session on (load
| > |    "gclload.lsp") mirroring yours, and my gdb trace looks a lot
| > |    better.  I think the key is not so much the output of bt, but
| > |    rather:
| > |
| > | Run till exit from #0  0x0041f7b0 in Leval () at eval.c:1171
| > | Warning:
| > | Cannot insert breakpoint 0.
| > | Error accessing memory address 0x104bfe66: Input/output error.
| > |
| > |    This is an address in the 'hole' or relocatable area on your
| > |    system, and so should never appear as a stack address.
| >
| > Pardon my lack of understanding but when you say "'hole' or relocatable
| > area" do you mean that those terms are synonymous or that they are two
| > alternative memory location categories into which the address might be
| > falling?
|
| Here's a rough sketch of the memory layout:
|
| dbegin -- heap_end
| hole
| relocatable area
| core_end
|
| All compiled lisp functions should be allocated as contiguous pages in
| the heap, i.e. before heap_end.

Aha.  Thanks for that.

Cheers

Mike Thomas.