Re: [Axiom-developer] 2.7 build

[Camm Maguire]

Greetings!

Waldek Hebisch <address@hidden> writes:

> I am now testing yesterday gcl-cvs.  I have set up safety to 3.  I hit
> two problems.  One is segfault -- it went away when I tried to debug
> it:
> 
> 
> )compile "RADCAT.spad"
> 
> Segmentation violation: c stack ok:signalling error
>    >> System error:
>    Condition in MAKE-INPUT-FILENAME [or a callee]: INTERNAL-SIMPLE-ERROR: 
> Caught fatal error [memory may be damaged]: Segmentation violation.
> 
> 
> I am somewhat worried: this is a first time I see a segfault in safety 3
> build. 
> 

As I mentioned a while ago, I'm trying to implement a more reasonable
(e.g. faster) safety 3, partially in response to your ealier request.
The older mode is still available at (the non-standard) safety 4.  It
would not surprise me if there are not a few issues to work out, but
the ansi-test suite, which is compiled at safety 3, is working fine.

For quick debugging of segfaults, run with )set break break and )lisp
(si::use-fast-links nil), then :bt at the break.  For robust
debugging, build gcl with --enable-debug and run under gdb.

I think the work-around you posted in your patch earlier regarding
universal-error-handler effectively disables error reporting, but am
not completely sure.  In your tree, I've tried simply removing the GCL
from #-(or gcl ccl) above and commenting out the
universal-error-handler embedding with (apparently) successful
results.  

This said, I have seen a segfault in your tree at the interpsys stage
which I would love to chase down.  Stephen's success has led me to
believe this is something specific to your tree, but GCL should
ideally never segfault.  Would it be possible for you and Stephen to
isolate what differences in your trees allow him to proceed well into
the algebra stage, but stops your tree shortly after interpsys? 

To be most efficient, it would be absolutely fantastic if you could
boil the error down to a simple example in lisp akin to Stephen's very
helpful reports of late.  My problem is that I do not know the axiom
sources nearly as well as the GCL sources -- it will therefore take
quite a while simply to find the relevant function leading to the
error.  

For example, in the report below ...

> The second problem is that the function |ICformat| apparently is
> miscompiled, Lisp code differs only trivially from code in 2.6.8
> build.  In particular at the beggining we have:
> 
> (DEFUN |ICformat| (|u|)
>   (PROG (|v| |l'| |l1| |l|)
>     (RETURN
>       (SEQ (COND
>              ((ATOM |u|) |u|)
>              ((AND (PAIRP |u|) (EQ (QCAR |u|) '|has|))
>               (|compHasFormat| |u|))
>              ((OR (AND (PAIRP |u|) (EQ (QCAR |u|) 'AND)
>                        (PROGN (SPADLET |l| (QCDR |u|)) 'T))
>                   (AND (PAIRP |u|) (EQ (QCAR |u|) '|and|)
>                        (PROGN (SPADLET |l| (QCDR |u|)) 'T)))
>               (SPADLET |l|
>                        (REMDUP (PROG (#1=#:G7955)

I take it this source is generated by some other function in axiom
which is malfunctioning, (akin to the writing of #<compiled function
...> in the generated lisp sources I reported earlier).  What is this
function?  How do I run it to produce the above output?  I take it the
difference lies in the gensym above -- this appears clearly wrong, and
indicates an error either in GCL's compilation of the function that
generates this source, or a mistake in one of the patches applied in
your tree.  Stephen, can you reproduce this?

> 
> 
> however, the call:
> 
> (|ICformat| '(|and| |foo| |bar| |foo|))
> 
> in 2.7.0 falls to the end and signals error, while in 2.6.8 compiled
> Axiom it works OK.  It looks that Steve had similar problem (but later
> wrote that it works OK).
> 

I don't see how this is related to Stephen's earlier report regarding
logical expression evaluation -- am I missing something?  It appears
we have a printing problem in your tree somewhere.

> One extra remark: the extra PROG which I saw previously seem to be
> gone -- I am not sure if it is safety 3 or something in gcl changed.
> But now I see:
> 
> (DEFUN |ALIST;dictionary;$;1| ($) (SPADCALL NIL (QREFELT $ 11)))
> 
> (the same as in other dialects), while earlier 2.7 gave me:
> 
> (DEFUN |ALIST;dictionary;$;1| ($)
>   (PROG () (RETURN (SPADCALL NIL (QREFELT $ 11)))))
> 

These are equivalent in lisp, but it still indicates some instability
in the axiom code generator.  There is nothing in GCL  that I can see
at the moment that would automatically make this conversion.

Please let me know if my suggestions above are unworkable.

BTW, am assuming we are still working with the source produced by svn
update in wh-sandbox as modified by the patches your posted.  If the
source tree is different, a complete set of instructions describing
how to reproduce this would be most helpful.

Take care,

> -- 
>                               Waldek Hebisch
> address@hidden 
> 
> 
> _______________________________________________
> Axiom-developer mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/axiom-developer
> 
> 
> 

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