Greetings! Waldek Hebisch <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > > > _______________________________________________ > Axiom-developer mailing list > Axiom-developer@nongnu.org > http://lists.nongnu.org/mailman/listinfo/axiom-developer > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
