Custom Query (1030 matches)

During compilation (often if not always during compilation of some file in "ccl:level-0;ARM;"), our build system sometimes gets the following error (or something very, very much like it):

> Error: value 0 is not of the expected type LIST.
> While executing: MEMEQL, in process listener(1).

This is ultimately due to the fact that *FEATURES* is getting bound to '(0 . 0) in COMPILE-FILE, but it's not clear how/why that happens.

In the backtrace in:

​http://setf.clozure.com:8010/builders/linuxarm/builds/72/steps/shell_2/logs/stdio

the local variable VALUES has the value ((0 . 0)), and *FEATURES* is bound to the CAR of that value (via PROGV.) VALUES is effectively bound to the value returned by:

(list (append nil *features*))

I've seen this happen, but haven't yet been able to determine why. There are lots of suspects ...

You can see a description of the problem and a solution at: ​http://common-lisp.net/pipermail/asdf-devel/2010-October/001708.html

A trace is shown at: ​http://paste.lisp.org/+2H95 [This paste will automatically go away in 6 days.]

In a nutshell, ASDF2 will unintern portions of itself if ASDF is already loaded and it is loaded again during the build process.

The solution is to start ccl with the --no-init option before invoking (ccl:rebuild-ccl :full t) so that any "(require :asdf)" form in .ccl-init is bypassed.

I don't think any code changes need be done to ccl, but it would be nice if something would be mentioned in the ccl documentation, otherwise this conflict between asdf and ccl is going to show up again.

Perhaps section "3.3 Building Everything" of the Clozure CL Documentation would be a good place to document this issue.

Very occasionally, one sees something like (from memory) :

Error: wrong number of args to FOO:
       2 arguments provided, 2 accepted

(however exactly that's presented/worded.)

A working theory is that that's icache-related and that the comparison of nargs with a constant and the conditional UUO that follows are in different cache lines and some instruction other than the comparison is actually executed instead. (That's a working theory only because this error was a symptom of failure to flush the icache on an iOS system.)

If it happens again, we should try to determine the address of the code vector and see if it's plausible that the first and second instructions are in different cache lines.

(The lisp kernel -may- try to determine the cache line size from information in the ELF aux vector or via sysctl or something like that; I'm not sure if it does, and it's unlikely that the value is used.)