Lisp HUG Maillist Archive

Foreign Language Interface stack overflow problem (lw5 32bit linux)

Hi all,

I'm having a strange problem with the fli functionality.

I'm using this library http://common-lisp.net/project/osicat/ in one
of my project. Osicat has a single c file (produces a so file) and
the corresponding fli binding.

The issue I'm facing is that the location of the osicat_glue.so file
in my development machine is different from the target machine.

As a result, I cannot use absolute path when I register the module.

The fli manual states that:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 
;; lw50/FLI/html/fli-117.htm#marker-1058727
register-module name  &key connection-style  lifetime  real-name  => name

If a full pathname is not specified for the module, then it is searched for.

On Linux, the search is conducted in this order:
   1. Directories on the user's LD_LIBRARY path environment variable.
   2. The list of libraries specified in /etc/ld.so.cache .
   3. /usr/lib , followed by /lib .

If connection-style is :automatic then the system automatically
connects to a dynamic library when it needs to resolve currently
undefined foreign symbols.

If connection-style is :manual then the system only connects to the
dynamic library if the symbol to resolve is explicitly marked as
coming from this module via the :module keyword of functions such as
define-foreign-function.

If connection-style is :immediate then the connection to the dynamic
library is made immediately. This checks that the library can actually
be loaded before its symbols are actually needed: an error is
signalled if loading fails.
;; end 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;


So I register the module like this:

(fli:register-module "osicat"
                     :real-name (pathname "osicat_glue.so")
                     :connection-style :automatic)

Then I set my LD_LIBRARY_PATH to where osicat_glue.so is located and
run the delivery script.

% cd /libs/cl/osicat/

% export LD_LIBRARY_PATH=`pwd`

% /usr/lib/LispWorks/lispworks-5-0-0-x86-linux -tty -init delivery.lisp

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 
;; delivery.lisp

(load-all-patches)

#-asdf (load "/libs/cl/asdf")

(setq asdf:*central-registry*
      (append '("/libs/cl/uffi/" "/libs/cl/osicat/")
              asdf:*central-registry*))

(defun do-it ()
  (format t "hello~%")
  (quit))

(compile 'do-it)

(asdf:oos 'asdf:load-op :osicat)

(deliver 'do-it "do-it" 0 :console :input :multiprocessing t)

(lispworks:quit)
;; end 


However, at the middle of the delivery, it blew the stack.

Total Size 24551K, Allocated 21737K, Free 2466K

Shaking stage : Saving image

Stack overflow (stack size 20478).
  1 (continue) Extend stack by 50%.
  2 Extend stack by 300%.
  3 Supply a better value for *default-pathname-defaults*.

Type :b for backtrace, :c <option number> to proceed,  or :? for other options

....... ;; repeats
Call to FLI::LOOK-FOR-LIBRARY-IN-PATH
Call to FLI::SEARCH-IN-LD-LIBRARIES
Call to FLI::LOAD-DLL
Call to FLI::CONNECT-TO-EXTERNAL-MODULE
Call to FLI::INSTALL-EXTERNAL-SYMBOL-FOR-MODULE
Call to FLI::INSTALL-FOREIGN-SYMBOL-OR-ERROR
Call to EXTERNAL-FORMAT::EF-CALL-WITH-RAW-FILE-NAME
Call to FLI::LOOK-FOR-LIBRARY-IN-PATH
Call to FLI::SEARCH-IN-LD-LIBRARIES
Call to FLI::LOAD-DLL
Call to FLI::CONNECT-TO-EXTERNAL-MODULE
Call to FLI::INSTALL-EXTERNAL-SYMBOL-FOR-MODULE
Call to FLI::INSTALL-FOREIGN-SYMBOL-OR-ERROR
Call to EXTERNAL-FORMAT::EF-CALL-WITH-RAW-FILE-NAME
....... ;; repeats



If I change the connection-style from :automatic to :immediate, then I 
can delivery the image just fine.

(fli:register-module "osicat"
                     :real-name (pathname "osicat_glue.so")
                     :connection-style :immediate) 
                                 

Delivery successful - do-it
4.476u 0.076s 0:04.55 99.7%     0+0k 0+0io 0pf+0w


However, when I run the delivered image, it either get killed or
overflow the stack. I tried creating a simple c file with a single
dummy function and call it from a simple lisp problem, and I couldn't
reproduce the problem.

If anyone has a clue that can help me diagnose this problem I'd
appreciate your help.

Thanks,
-- Mac

                                         

% ./do-it
Killed
% ./do-it
Killed
% ./do-it
Killed
% ./do-it
Killed
% ./do-it

Stack overflow (stack size 20478).
  1 (continue) Extend stack by 50%.
  2 Extend stack by 300%.
  3 Supply a better value for *default-pathname-defaults*.

Type :b for backtrace, :c <option number> to proceed,  or :? for other options

CL-USER 1 : 1 > :b
....... ;; repeats                                         
Call to FLI::LOAD-DLL
Call to FLI::CONNECT-TO-EXTERNAL-MODULE
Call to FLI::INSTALL-EXTERNAL-SYMBOL-FOR-MODULE
Call to FLI::INSTALL-FOREIGN-SYMBOL-OR-ERROR
Call to ENVIRONMENT-VARIABLE
Call to FLI::PARSE-LD-LIBRARY-PATH
Call to FLI::FULL-LIBRARY-PATH-LIST
Call to FLI::SEARCH-IN-LD-LIBRARIES
Call to FLI::LOAD-DLL
Call to FLI::CONNECT-TO-EXTERNAL-MODULE
Call to FLI::INSTALL-EXTERNAL-SYMBOL-FOR-MODULE
Call to FLI::INSTALL-FOREIGN-SYMBOL-OR-ERROR
Call to ENVIRONMENT-VARIABLE
Call to FLI::PARSE-LD-LIBRARY-PATH
Call to FLI::FULL-LIBRARY-PATH-LIST
Call to FLI::SEARCH-IN-LD-LIBRARIES
....... ;; repeats



Re: Foreign Language Interface stack overflow problem (lw5 32bit linux)


FYI, this problem may be related to how uffi translate the 
LOAD-FOREIGN-LIBRARY call to 

(fli:register-module module-name :real-name path 
                     :connection-type :immediate)

If I replace it with

(fli:register-module 
   (concatenate 'string 
                (pathname-name file) "." (pathname-type file))

and change all the uffi:def-function's :module keyword to
"libxxx.so" then it works ok.

I'll debug this further later on and post the results here.

Thanks.



Updated at: 2020-12-10 08:47 UTC