Custom Query (1030 matches)

When I try to load usocket, an error "Foreign function not found: WIN64::|gethostname|" is displayed.

I am running CCL 64-bit on Windows 7 64-bit.

wx86cl64.exe -I ccl.save Welcome to Clozure Common Lisp Version 1.9-r15765 (WindowsX8664)! ? (ql:quickload "usocket") To load "usocket":

Load 1 ASDF system:

usocket

; Loading "usocket" Read error between positions 220 and 317 in C:/Users/Gerry/quicklisp/dists/quicklisp/software/usocket-0.6.0.1/backend/openmcl.lisp.

Error: Foreign function not found: WIN64::|gethostname| While executing: CCL::LOAD-EXTERNAL-FUNCTION, in process listener(1). Type :POP to abort, :R for a list of available restarts. Type :? for other options.

1 >

The error seems to be in the following code:

(defun get-host-name ()

(ccl::%stack-block ((resultbuf 256))

(when (zerop (#_gethostname resultbuf 256))

(ccl::%get-cstring resultbuf))))

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

Qt-webkit uses pthread_key_create with a destructor, and inside that destructor it calls back into lisp. But apparently lisp-thread infrastructure is already dismantled when the destructor is called.

Here's a test-case:

// gcc test.c -lpthread -shared -o test.so -fPIC

#include <pthread.h>

void finish(void* arg) {
  int (*f)(int, int) = (int(*)(int,int))arg;
  f(1,2);
}

int test (int (*f)(int, int))
{
  pthread_key_t key;
  pthread_key_create(&key, finish);
  pthread_setspecific(key, f);
}

(eval-when (:compile-toplevel :load-toplevel :execute)
  (asdf:load-system :cffi))

(cffi:load-foreign-library "/tmp/test.so")

(cffi:defcfun (test-c "test") :int
  (function :pointer))

(cffi:defcallback (test-callback)
    :short ((a :int) (b :int))
  (print (list a b))
  (finish-output)
  1)

(defun test ()
  (ccl:process-run-function
   nil
   (lambda () (test-c (cffi:get-callback 'test-callback)))))

(test)

One idea I had for fixing this is creating a new thread-key with a value of 1. The order of destructor execution is not specified, but it's specified that they are called PTHREAD_DESTRUCTOR_ITERATIONS times if the key still has a value. So, when the destructor is called the first time, it'll just set its value to 0 and do nothing, then when it's called with 0, do thread clean up. That way other key destructor will get a chance to be called on the first iteration before the clean up is completed.