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

[Mike Thomas]

Hi Camm.

| Greetings!
|
| 1) Please excuse any possible dropped email  on my part -- we've had
|    system problems.

No worries.

| 2) Please check out the configure patch skipping the sbrk test when
|    there is no sbrk.  Aurelien, it would be helpful if you could do
|    the same.

It worked here, thank you, apart from a spelling mistake:

checking for sbrk... no: WARNING you must beable to emulate sbrk: as on
mingw or macosx

| 3) Regarding gcc optimization on Windows and test results thereof --
|    this is encouraging!  While it is not impossible that we still have
|    a problem in GCL, this increases the likelihood in my mind that gcc
|    on mingw is the issue.  Mike, do you know what differs if anything
|    between mingw gcc and stock gcc?

Apart from the replacement of Unixy things like fork() which really only
affect the way the compiler runs rather than the code it generates I
couldn't say.

I believe that the Cygwin and MinGW32 code generators, however, are the
same.  Likewise that only things which allow MS Visual C++ compatibility are
different from the Linux i386 version, but I can't really be sure.  An
example of the latter, by the way is the -mms-bitfields switch which I use
to ensure equivalent handling of bitfields to MSVC++ to allow GCL libraries
to be compatible in the event that someone decides to build a GCL DLL.

I'll look further into this but I suspect that it will be difficult to get
much specific information without examining the gcc source, which I am
reluctant to do.

I did quite a lot of fooling around with compiler options a year or two ago
when I first started working with GCL and again when the ANSI build problem
first showed up, but I'll aim to try some more soon as the gcc version has
moved on since then and we are looking at different code.


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


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


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


|  This could
|    either indicate a problem, or a gdb corruption.  Perhaps you could
|    run with b *0x104bfe66 and see if the instruction pointer ever gets
|    to this address?


OK thanks; I hadn't realised before that you could feed a function address
to "break".  Handy to know and will try this out.


|
| 7) Re debugging deep into a lisp job -- the way to do this is to take
|    the test showing the first sign of trouble, and inserting (si::break
|    "foo") in its defining lisp code (found in the appropriate .lsp
|    file under ansi-tests).  One can then run a lisp debugging session
|    on top of a gdb debugging session, as Dr. Schleter used to point
|    out.

Another thing I had never heard of which sounds very helpful.

I was imagining (and in fact recently implemented but not yet checked in)
(say three) break commands which were essentially do nothing special forms
implemented in C land.  You can then set gdb breaks on one or more of those
forms' underlying C function after inserting them at different levels in
nested iterative lisp code so that you could break at a certain stage at a
higher level and then if necessary set a gdb break on the form already
present in the lower level of the iteration when you felt the need to refine
your level of breaking.

|
| 8) Re deadline of a fortnight -- sounds good to me.  Hopefully we'll be
|    ready well in advance of this.

Great.

I'll let you know how things progress.

Cheers

Mike Thomas.