[Asdf-devel] ASDF test failure on MKCL linux

[Jean-Claude Beaudoin]

On Sun, Oct 5, 2014 at 11:03 PM, Faré <fahree at gmail.com> wrote:

> test-try-refinding.script is a relatively new test (introduced shortly
> before the 3.1.3 release), so its failure might not be a regression in
> ASDF if none of us tested 3.1.3 with MKCL (did we?). Now, infinite
> looping is certainly a bad failure mode in the test. This looks like a
> MKCL-specific bug, though:
>
> If I replace the culprit loop (just before (DBG "Refinding test
> successful.")) by this debugging variant, I find that the variable
> tried-once is somehow magically reset to NIL after having been set to
> T, and that, even if it's a defparameter instead of a lexical variable
> (I tried both), but happily not with a defvar (where the script only
> fails, doesn't infinitely loops). The problem is that it restarts the
> wrong frame! Instead of resuming after the handler-bind handlers from
> test-try-refinding.script, it resumes a frame way up there in the call
> stack in function run-test-script in script-support.lisp, that has its
> own handler-bind (but no restart) via macro with-test. Looks like a
> MKCL compiler bug.
>
> (defvar tried-once nil)
> (assert
>  ;;(let ((tried-once nil))
>   (with-asdf-cache (:override t)
>     (handler-bind
>         ((asdf:missing-component
>            #'(lambda (c)
>                (DBG "Caught MISSING-COMPONENT condition.")
>                (nest
>                 (progn (DBG 1 tried-once))
>                 (if tried-once (error c)) ;; avoid infinite looping
>                 (progn (DBG 2))
>                 (progn (setf tried-once t))
>                 (progn (DBG 3 tried-once))
>                 (let ((missing (asdf::missing-requires c)))
>                   (assert (equal missing "test-asdf/force1"))
>                   (setf asdf:*central-registry* *old-registry*)
>                   (invoke-restart 'asdf:retry))))))
>       (asdf:find-system "test-asdf/force1" t))));;)
>
> Output:
> Running test-try-refinding.script with mkcl-1.1.10-linux-x64
> ;;; Loading "test-try-refinding.script"
> ; Loading system definition for test-asdf from
> /home/tunes/cl/asdf/test/test-asdf.asd
> ;;; Loading "/home/tunes/cl/asdf/test/test-asdf.asd"
> ; Registering #<SYSTEM "test-asdf">
> ; Registering #<SYSTEM "test-asdf/force1">
> Clearing the caches and finding.
> Correctly failed to find system.
> Caught MISSING-COMPONENT condition.
> 1
>   ASDF-TEST::TRIED-ONCE => NIL
> 2
> 3
>   ASDF-TEST::TRIED-ONCE => T
> Running test-try-refinding.script with mkcl-1.1.10-linux-x64
> ;;; Loading "test-try-refinding.script"
> ... repeat ad vitam aeternam
>
>
Wow! That is bad indeed! I will try to fix it in the coming 24 hours.
Thank you for the bug report.


>
> PS: unrelatedly, several bugs were recently fixed in clasp and ECL
> that may or may not be present in MKCL; check the (not very active,
> this year) git log of ECL for details.
>

I do read the ECL git log and bug list on a frequent and regular basis and
I try in MKCL
each test case mentioned in them when they seem relevant. But the fact is
that by now
MKCL and ECL have evolved far enough apart that a large (and growing
larger) part
of those ECL bug reports/fix don't apply to MKCL anymore. I keep on reading
though...


>
> Robert: I suggest we disable this test for MKCL until JCB fixes his
> compiler bug, and/or use defvar as above.
>

As I said here below, I may take a day or two before I have a fix for this
one.
So, please, do the workaround in the meantime.


>
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
> http://fare.tunes.org
> As the Chinese say, 1001 words is worth more than a picture.  — John
> McCarthy
>
>
> On Sun, Oct 5, 2014 at 9:20 PM, Jean-Claude Beaudoin
> <jean.claude.beaudoin at gmail.com> wrote:
> >
> > On Sun, Oct 5, 2014 at 8:57 PM, Faré <fahree at gmail.com> wrote:
> >>
> >> Dear JCB,
> >>
> >> You suggestion indeed fixes test-bundle.script, but now
> >> this test loops indefinitely for me, using the latest mkcl from git:
> >> make t l=mkcl t=test-try-refinding.script
> >>
> >
> > This one does not look like a mere typo. I will have to investigate
> deeper
> > but I don't have much spare cycles right now so it may take a little
> while
> > (1-2 days, I hope).
> >
> > I hope this is not blocking something essential, is it?
> >
> > Cheers,
> >
> > Jean-Claude
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20141006/0e8b90e3/attachment.html>