[Gsll-devel] clisp&cffi: broken foreign functions in saved images
Hi, I do this: $ clisp -x '(asdf:operate 'asdf:load-op :gsll) (saveinitmem "gsll" :executable t)' $ ./gsll
(gsll:make-chebyshev 1)
FFI::FOREIGN-CALL-OUT: no dynamic object named "gsl_cheb_alloc" in library :DEFAULT this indicates a bug somewhere between cffi and gsll. specifically, the definition of the foreign function gsl_cheb_alloc should specify that it is to be found in "libgsl.so", not in :default. moreover, when I do the (not so) trivial thing: (ffi:default-foreign-language :stdc) (ffi:open-foreign-library "libgslcblas.so") (ffi:def-call-out gsl_cheb_alloc (:library "libgsl.so") (:arguments (n ffi:int)) (:return-type ffi:c-pointer)) (gsl_cheb_alloc 10) ;; ==> #<FOREIGN-ADDRESS #x0000000005503380> (saveinitmem "foo" :executable t) (quit) ./foo (ffi:open-foreign-library "libgslcblas.so") (gsl_cheb_alloc 10) #<FOREIGN-ADDRESS #x0000000001D9F4C0> i.e., if the foreign function definition includes the correct library name, the function will work automatically[*] even in the saved image. So, since I am not quite sure where the bug is hiding, I am reporting this to both gsll and cffi lists. Thanks. Sam. [*] apparently, libgsl.so cannot be loaded before libgslcblas.so is. how do people specify such dependencies?!
Sam, I'm going to push that off on CFFI. I think I am opening and using the GSL libraries the CFFI-approved way, so it seems that CFFI is doing something CLISP-wrong. And yes, you do have to load the cblas library before the main GSL library. The way the dependency is specified is simply by loading them in the right order. On a related issue, I previously noticed multiple test failures in running gsll-tests in CLISP. I'm not knowledgeable enough to identify the source, but as I recall, they were of only one or two types and related to the foreign calls. Perhaps with your expertise you can run the tests and give some insight on the solution? Unfortunately I tried to repeat the tests now and got a new error I've not seen before. In compiling conditions.lisp, there is an error *** - EVAL: variable +EDOM+ has no value This should be defined by the form at the top of the file, #.(cons 'progn (loop for i from (cffi:foreign-enum-value 'gsl-errorno :continue) to (cffi:foreign-enum-value 'gsl-errorno :eof) for name = (string (cffi:foreign-enum-keyword 'gsl-errorno i)) collect `(defconstant ,(intern (format nil "+~:@(~a~)+" name) :gsll) ,i))) which expands to (PROGN (DEFCONSTANT +CONTINUE+ -2) (DEFCONSTANT +FAILURE+ -1) (DEFCONSTANT +SUCCESS+ 0) (DEFCONSTANT +EDOM+ 1) (DEFCONSTANT +ERANGE+ 2) (DEFCONSTANT +EFAULT+ 3) (DEFCONSTANT +EINVAL+ 4) (DEFCONSTANT +EFAILED+ 5) (DEFCONSTANT +EFACTOR+ 6) (DEFCONSTANT +ESANITY+ 7) (DEFCONSTANT +ENOMEM+ 8) (DEFCONSTANT +EBADFUNC+ 9) (DEFCONSTANT +ERUNAWAY+ 10) (DEFCONSTANT +EMAXITER+ 11) (DEFCONSTANT +EZERODIV+ 12) (DEFCONSTANT +EBADTOL+ 13) (DEFCONSTANT +ETOL+ 14) (DEFCONSTANT +EUNDRFLW+ 15) (DEFCONSTANT +EOVRFLW+ 16) (DEFCONSTANT +ELOSS+ 17) (DEFCONSTANT +EROUND+ 18) (DEFCONSTANT +EBADLEN+ 19) (DEFCONSTANT +ENOTSQR+ 20) (DEFCONSTANT +ESING+ 21) (DEFCONSTANT +EDIVERGE+ 22) (DEFCONSTANT +EUNSUP+ 23) (DEFCONSTANT +EUNIMPL+ 24) (DEFCONSTANT +ECACHE+ 25) (DEFCONSTANT +ETABLE+ 26) (DEFCONSTANT +ENOPROG+ 27) (DEFCONSTANT +ENOPROGJ+ 28) (DEFCONSTANT +ETOLF+ 29) (DEFCONSTANT +ETOLX+ 30) (DEFCONSTANT +ETOLG+ 31) (DEFCONSTANT +EOF+ 32)) Shouldn't that be enough to define +EDOM+? Sorry to throw more bugs back at you, but I figure you know the most about CLISP and I know very little. Thanks. Liam On Thu, Aug 20, 2009 at 12:01 PM, Sam Steingold<sds@gnu.org> wrote:
Hi,
I do this:
$ clisp -x '(asdf:operate 'asdf:load-op :gsll) (saveinitmem "gsll" :executable t)' $ ./gsll > > (gsll:make-chebyshev 1) FFI::FOREIGN-CALL-OUT: no dynamic object named "gsl_cheb_alloc" in library :DEFAULT
this indicates a bug somewhere between cffi and gsll. specifically, the definition of the foreign function gsl_cheb_alloc should specify that it is to be found in "libgsl.so", not in :default.
moreover, when I do the (not so) trivial thing:
(ffi:default-foreign-language :stdc) (ffi:open-foreign-library "libgslcblas.so") (ffi:def-call-out gsl_cheb_alloc (:library "libgsl.so") (:arguments (n ffi:int)) (:return-type ffi:c-pointer)) (gsl_cheb_alloc 10) ;; ==> #<FOREIGN-ADDRESS #x0000000005503380> (saveinitmem "foo" :executable t) (quit)
./foo (ffi:open-foreign-library "libgslcblas.so") (gsl_cheb_alloc 10) #<FOREIGN-ADDRESS #x0000000001D9F4C0>
i.e., if the foreign function definition includes the correct library name, the function will work automatically[*] even in the saved image.
So, since I am not quite sure where the bug is hiding, I am reporting this to both gsll and cffi lists.
Thanks. Sam.
[*] apparently, libgsl.so cannot be loaded before libgslcblas.so is. how do people specify such dependencies?!
_______________________________________________ Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
Liam, On Thu, Aug 20, 2009 at 9:10 PM, Liam Healy<lhealy@common-lisp.net> wrote:
Unfortunately I tried to repeat the tests now and got a new error I've not seen before. In compiling conditions.lisp, there is an error *** - EVAL: variable +EDOM+ has no value This should be defined by the form at the top of the file, #.(cons 'progn (loop for i from (cffi:foreign-enum-value 'gsl-errorno :continue) to (cffi:foreign-enum-value 'gsl-errorno :eof) for name = (string (cffi:foreign-enum-keyword 'gsl-errorno i)) collect `(defconstant ,(intern (format nil "+~:@(~a~)+" name) :gsll) ,i)))
I think you need to replace "cons 'progn" with "list* 'eval-when '(load compile eval)" -- Sam Steingold <http://sds.podval.org>
On Thu, Aug 20, 2009 at 11:29 PM, Sam Steingold<sds@gnu.org> wrote:
Liam,
On Thu, Aug 20, 2009 at 9:10 PM, Liam Healy<lhealy@common-lisp.net> wrote:
Unfortunately I tried to repeat the tests now and got a new error I've not seen before. In compiling conditions.lisp, there is an error *** - EVAL: variable +EDOM+ has no value This should be defined by the form at the top of the file, #.(cons 'progn (loop for i from (cffi:foreign-enum-value 'gsl-errorno :continue) to (cffi:foreign-enum-value 'gsl-errorno :eof) for name = (string (cffi:foreign-enum-keyword 'gsl-errorno i)) collect `(defconstant ,(intern (format nil "+~:@(~a~)+" name) :gsll) ,i)))
I think you need to replace "cons 'progn" with "list* 'eval-when '(load compile eval)"
-- Sam Steingold <http://sds.podval.org>
Right, I tried the eval-when and it works, so I've checked that in. Which brings me to the real CLISP errors, (lisp-unit:run-tests) ends after a few units with *** - handle_fault error2 ! address = 0x8 not in [0x33497c000,0x3350de6d8) ! SIGSEGV cannot be cured. Fault address = 0x8. Do you see that? Do you know what could be causing it? Liam
On Sat, Aug 22, 2009 at 3:48 PM, Liam Healy<lhealy@common-lisp.net> wrote:
Which brings me to the real CLISP errors, (lisp-unit:run-tests) ends after a few units with *** - handle_fault error2 ! address = 0x8 not in [0x33497c000,0x3350de6d8) ! SIGSEGV cannot be cured. Fault address = 0x8.
Do you see that? Do you know what could be causing it?
chances are - bad ffi forms. if you can create an isolated test case, that would be a great help! -- Sam Steingold <http://sds.podval.org>
On Sun, Aug 23, 2009 at 1:59 AM, Sam Steingold<sds@gnu.org> wrote:
On Sat, Aug 22, 2009 at 3:48 PM, Liam Healy<lhealy@common-lisp.net> wrote:
Which brings me to the real CLISP errors, (lisp-unit:run-tests) ends after a few units with *** - handle_fault error2 ! address = 0x8 not in [0x33497c000,0x3350de6d8) ! SIGSEGV cannot be cured. Fault address = 0x8.
Do you see that? Do you know what could be causing it?
chances are - bad ffi forms. if you can create an isolated test case, that would be a great help!
OK, this will cause the crash: (make-chebyshev 40 'chebyshev-step 0.0d0 1.0d0) I traced this down to the reinitialize-instance method for chebyshev, which expands to something like (DEFMETHOD REINITIALIZE-INSTANCE :AFTER ((OBJECT CHEBYSHEV) &KEY FUNCTIONS LOWER-LIMIT UPPER-LIMIT &AUX (#:CBSTRUCT (MAKE-CBSTRUCT 'FNSTRUCT (WHEN (DIMENSION-NAMES OBJECT) (MAPPEND 'LIST (DIMENSION-NAMES OBJECT) (DIMENSIONS OBJECT))) 'FUNCTION 'CHEBYSHEV-CBFN0))) (DECLARE (TYPE DOUBLE-FLOAT LOWER-LIMIT) (TYPE DOUBLE-FLOAT UPPER-LIMIT) (IGNORE #:CBSTRUCT FUNCTIONS) (SPECIAL CHEBYSHEV-DYNFN0)) (WITH-FOREIGN-OBJECTS ((#:CBSTRUCT 'T)) (MAKE-FUNCALLABLES-FOR-OBJECT OBJECT) (SETF CHEBYSHEV-DYNFN0 (NTH 0 (FUNCALLABLES OBJECT))) (LET ((#:CRETURN (FOREIGN-FUNCALL "gsl_cheb_init" :POINTER (MPOINTER OBJECT) :POINTER #:CBSTRUCT :DOUBLE LOWER-LIMIT :DOUBLE UPPER-LIMIT :INT))) (CHECK-GSL-STATUS #:CRETURN 'REINITIALIZE-INSTANCE) (TRIVIAL-GARBAGE:FINALIZE OBJECT (LAMBDA () (FOREIGN-FREE #:CBSTRUCT))) (VALUES OBJECT)))) so I guess the crash is in the cffi:foreign-funcall of gsl_cheb_init. Could this be a case of incorrect expansion to CLISP ffi in CFFI? Liam
Sam, Did you ever resolve this? Was my guess correct about the CFFI expansion of foreign-funcall for CLISP? Liam On Sun, Aug 23, 2009 at 12:15 PM, Liam Healy <lhealy@common-lisp.net> wrote:
On Sun, Aug 23, 2009 at 1:59 AM, Sam Steingold<sds@gnu.org> wrote:
On Sat, Aug 22, 2009 at 3:48 PM, Liam Healy<lhealy@common-lisp.net> wrote:
Which brings me to the real CLISP errors, (lisp-unit:run-tests) ends after a few units with *** - handle_fault error2 ! address = 0x8 not in [0x33497c000,0x3350de6d8) ! SIGSEGV cannot be cured. Fault address = 0x8.
Do you see that? Do you know what could be causing it?
chances are - bad ffi forms. if you can create an isolated test case, that would be a great help!
OK, this will cause the crash: (make-chebyshev 40 'chebyshev-step 0.0d0 1.0d0) I traced this down to the reinitialize-instance method for chebyshev, which expands to something like
(DEFMETHOD REINITIALIZE-INSTANCE :AFTER ((OBJECT CHEBYSHEV) &KEY FUNCTIONS LOWER-LIMIT UPPER-LIMIT &AUX (#:CBSTRUCT (MAKE-CBSTRUCT 'FNSTRUCT (WHEN (DIMENSION-NAMES OBJECT) (MAPPEND 'LIST (DIMENSION-NAMES OBJECT) (DIMENSIONS OBJECT))) 'FUNCTION 'CHEBYSHEV-CBFN0))) (DECLARE (TYPE DOUBLE-FLOAT LOWER-LIMIT) (TYPE DOUBLE-FLOAT UPPER-LIMIT) (IGNORE #:CBSTRUCT FUNCTIONS) (SPECIAL CHEBYSHEV-DYNFN0)) (WITH-FOREIGN-OBJECTS ((#:CBSTRUCT 'T)) (MAKE-FUNCALLABLES-FOR-OBJECT OBJECT) (SETF CHEBYSHEV-DYNFN0 (NTH 0 (FUNCALLABLES OBJECT))) (LET ((#:CRETURN (FOREIGN-FUNCALL "gsl_cheb_init" :POINTER (MPOINTER OBJECT) :POINTER #:CBSTRUCT :DOUBLE LOWER-LIMIT :DOUBLE UPPER-LIMIT :INT))) (CHECK-GSL-STATUS #:CRETURN 'REINITIALIZE-INSTANCE) (TRIVIAL-GARBAGE:FINALIZE OBJECT (LAMBDA () (FOREIGN-FREE #:CBSTRUCT))) (VALUES OBJECT))))
so I guess the crash is in the cffi:foreign-funcall of gsl_cheb_init. Could this be a case of incorrect expansion to CLISP ffi in CFFI?
Liam
On 8/23/09, Liam Healy <lhealy@common-lisp.net> wrote:
On Sun, Aug 23, 2009 at 1:59 AM, Sam Steingold<sds@gnu.org> wrote:
On Sat, Aug 22, 2009 at 3:48 PM, Liam Healy<lhealy@common-lisp.net> wrote:
Which brings me to the real CLISP errors, (lisp-unit:run-tests) ends after a few units with *** - handle_fault error2 ! address = 0x8 not in [0x33497c000,0x3350de6d8) ! SIGSEGV cannot be cured. Fault address = 0x8.
Do you see that? Do you know what could be causing it?
chances are - bad ffi forms. if you can create an isolated test case, that would be a great help!
OK, this will cause the crash: (make-chebyshev 40 'chebyshev-step 0.0d0 1.0d0)
not for me: [9]> (gsll:make-chebyshev 40 'gsll::chebyshev-step 0.0d0 1.0d0) #<GSLL:CHEBYSHEV for CHEBYSHEV-STEP, dimensions (1) #x00034D640FF8> [10]> this is the current clisp cvs head. maybe you could try that? sorry about the long delay. -- Sam Steingold <http://sds.podval.org>
participants (2)
-
Liam Healy -
Sam Steingold