Forgot to cc the list.

---------- Forwarded message ---------- From: Jean-Claude Beaudoin jean.claude.beaudoin@gmail.com Date: Mon, Apr 21, 2014 at 9:42 PM Subject: Re: [Asdf-devel] mkcl crashes during upgrade test To: Robert Goldman rpgoldman@sift.info

On Mon, Apr 21, 2014 at 4:33 PM, Robert P. Goldman rpgoldman@sift.infowrote:

On linux, all the upgrade tests just passed for me with the single exception of MKCL. I don't know what's going on with the following:

; Upgraded ASDF from version 3.0.3.0.1 to version 3.1.0.116 ;; ASDF, version 3.1.0.116 ;;; Warning: The following packages were referenced in compiled file (/home/rpg/common-lisp/asdf/bu\ ild/asdf.lisp) but do not exist yet: (ASDF/PARSE-DEFSYSTEM). Testing it Excessive universal-error-handler depth! Probable infinite recursion! ...

While loading a fasl file (most probably a version of asdf.fas in this case) a reference to a non-existent package was found. This should be a hard error and not a mere warning. The message mentions the source file the offending file was compiled from, not the real origin of the message, which is somewhat misleading.

The mention "Probable infinite recursion!" indicates that the debugger just went into a tail spin and crashed (a fairly common problem in MKCL 1.1.X) so what comes after is most probably a pile of pathological nonsense and should be ignored.

BTW, package ASDF/PARSE-DEFSYSTEM does not exists in ASDF 3.0.3.

I replaced the code that produced the warning in MKCL to signal an error instead. You'll find it in the MKCL 1.1.X git repository master head.

If you could cut-&-paste an exact transcript of what led to the message above it would be quite useful to pinpoint the exact origin of the incident.

When I start up MKCL, and push /home/rpg/common-lisp/asdf/ and /home/rpg/common-lisp/asdf/uiop/ onto asdf:*central-registry*, then (asdf:component-pathname (asdf:find-system "asdf")) does the right thing and (asdf:load-system "asdf") completes, returning T, and afterwards (ASDF:ASDF-VERSION) returns 3.1.0.116

So it seems like this might be a bug with the test infrastructure, instead of a bug with the actual upgrade.

It is probably as you say but MKCL 1.1.X could do a better job at not obfuscating the origin of the problem.