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 ...

On at least some fairly recent versions of OSX, using drag-and-drop to drag text around in the Cocoa IDE generates an FP exception (invalid operation IIRC). This happens deep in some CG text-drawing code that's invoked by CCL calling the superclass's #/mouseDown: method, and we report it as an arithmetic error. The error's likely to just be confusing and disruptive to the user.

We can work around this particular bug by disabling FP exceptions around the next-method call.

We generally try to report FP exceptions that occur in foreign code; this certainly makes sense if (for instance) #_sin is called as part of the implementation of CL:SIN. It's less clear that it's desirable or useful to try to detect and report FP exceptions that have nothing to do with CL math functions, though we've traditionally done so.

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.)