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

[Camm Maguire]

Greetings!

"Mike Thomas" <address@hidden> writes:

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

No problem, Mike!  Please -- keep life sane.  You are truly heroic to
be tackling the windows 'situation', which easily exceeds in
difficulty the 'dozen' or so other platforms I'm working with, so
whatever you feel is appropriate *is appropriate* :-).  

Vadim, any chance on your being able to relieve some of the pressure
off Mike?  The archives of this thread detail a few gdb runs which
need doing and investigating.


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

OK.  Can this test be isolated, with the failure preserved, and serve
as a test case?  My understanding now is that the suite fails to
complete on stable with the original optimization settings, but does
complete with one extra failure with -O and below.

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

With latest gcc too?

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

This is quite easy to do, and will get easier.  Build a stable ansi
gcl with debugging preferably, cd into the ansi-tests directory of the
unstable tree, (load "gclload1.lsp")(compile-and-load
"random-int-form.lsp")(in-package :cl-test) (loop-random-int-forms
1000 8).


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

Great!  Let us know ....

Take care,

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

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