Custom Query (1030 matches)

(defcallback foo (:double-float a 
                  :double-float b 
                  :double-float c 
                  :double-float d 
                  :double-float e
                  :double-float f
                  :double-float g 
                  :double-float)
  (format t "~&~s" (list a b c d e f g))
  (+ a b c d e f g))

(ff-call foo :double-float 1.0d0 :double-float 2.0d0 :double-float 3.0d0 :double-float 4.0d0 :double-float 5.0d0 :double-float 6.0d0 :double-float 7.0d0 :double-float) 

prints and returns:

(1.0D0 2.0D0 3.0D0 4.0D0 1.398752D-316 0.0D0 1.3987457D-316)
10.0D0

I'm fairly sure that the caller's putting arguments (after the first 4) in the wrong place (e.g., that the callback's right and the bug's in FF-CALL.)

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.