Custom Query (1030 matches)

I have run into this kind of problem many times with my EasyGui efforts, and thought it must be my own fault. But now I've come across it using the Search Files dialog, which is nothing to do with me. This kind of thing pops up in the AltConsole window:

Error: Array index 5 out of bounds for #<SLOT-VECTOR [CCL::SLOT-VECTOR ==> CCL::GVECTOR ==> T] #x136DC716> .

While executing: (:INTERNAL GUI::doSearch:|), in process Initial(0).

Type :POP to abort, :R for a list of available restarts. Type :? for other options.

1 >

It is not reliably repeatable.

fwiw, I have suspected that it is due to some race condition whereby instances of Cocoa subclasses get information enough added to them for some objc method to be dispatched, but the extra Lisp slots appropriate for the class have not yet been added. This is just a hunch, maybe helpful and maybe way off the mark.

When executing

(ccl:close-shared-libary (ccl:open-shared-libary "user32.dll"))

the error below appears:

Reader error: No external symbol named "CLOSE-SHARED-LIBARY" in package #<Package "CCL"> .

[Condition of type SIMPLE-ERROR]

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