Custom Query (1030 matches)

Historically, CCL has treated an exception that occurs in foreign code as being fatal; we don't in general know what foreign state may need to be unwound or whether the code that got the exception is reentrant, so the absolute best that we could do is a sort of "cross your fingers, pray, and signal a lisp error." Whether that's worth a try or not is a separate issue.

Relatively recent changes to the trunk allow us to note when SIGFPE is raised during execution of foreign code (at least on x8664); this is a good thing, in that it removes a little bit of overhead from every ff-call. This change exposes a subtle and long-standing bug.

When a thread gets an exception on Unix platforms, it stores the exception context in a TCR field, unmasks blocked signals, and waits for the exception lock. That makes sense if the exception occured during the execution of lisp code: if some other thread GCs while the thread in question is waiting, the GC thread will see that thread's pending exception context. If the exception occurs in foreign code, the GC thread should not see the pending exception context. (As I said, this is a longstanding bug; the SIGFPE handling just makes it theoretically more likely to occur.)

On Win64, a thread can be suspended or interrupted while in the process of returning from an exception and restoring its valence. We've assumed that a thread can only return from an exception if the exception occurred during execution of lisp code, so when pc-lusering our way out of exception return on Win64 we've assumed that we'll be resuming in lisp state; the SIGFPE handing in foreign code means that that assumption isn't valid, and we'll need to handle this more carefully.

The likelyhood of bad things happening is small (but non-zero.)

If we get an unrecoverable memory fault, we try to use the siginfo_t argument to the signal handler to describe the reason for the fault.

On Darwin, we handle exceptions at the Mach level and create the siginfo_t argument ourselves. I think that we do this to make the fault address easier to find, but I don't think that we set other fields in the siginfo_t to meaningful values, so the attempt to describe those fields often gives misleading results.

We should presumably either try harder to initialize the siginfo_t the way that a real SIGBUS or SIGSEGV would, or not trust our ability to describe the fault accurately.

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