3

I'm trying to run an executable with an Hunchentoot server and I'm getting (after an unusual high CPU usage):

<INFO> [17:55:14] weblocks/server server.lisp (start) -   
Starting weblocks WEBLOCKS/SERVER::PORT: 40001   
WEBLOCKS/SERVER::SERVER-TYPE: :HUNCHENTOOT DEBUG: T 

debugger invoked on a SB-INT:EXTENSION-FAILURE in thread
#<THREAD "main thread" RUNNING {1008C1EA13}>:
Don't know how to REQUIRE sb-cltl2.

Do you have any idea what's going on ? It works correctly on Slime where I use the start function.

(sbcl manual: http://www.sbcl.org/manual/#Customization-Hooks-for-Users)

In the main entry point, I try to capture the running thread so that I keep the server running on the foreground (my notes). This pattern worked with another clack-based web framework.

(defun start ()
  (weblocks/debug:on)
  (weblocks/server:start :port *port*))

(defun main ()
  (defvar *port* (find-port:find-port))
  (start)
  (handler-case (bt:join-thread (find-if (lambda (th)
                                             (search "hunchentoot" (bt:thread-name th)))
                                         (bt:all-threads)))
    (#+sbcl sb-sys:interactive-interrupt
      #+ccl  ccl:interrupt-signal-condition
      #+clisp system::simple-interrupt-condition
      #+ecl ext:interactive-interrupt
      #+allegro excl:interrupt-signal
      () (progn
           (format *error-output* "Aborting.~&")
           (uiop:quit 1))
    ;; for others, unhandled errors (we might want to do the same).
    (error (c) (format t "Woops, an unknown error occured:~&~a~&" c)))))

Or any indication of what could be the cause ?

Thanks again.

(I'm using 40ants' weblocks:reblocks branch)

SBCL Debian 1.2.4

edit I tried

export SBCL_HOME=/usr/local/lib/sbcl/

I build with

build:
    $(LISP) --quit \
        --eval '(ql:quickload "foo")' \
        --eval '(require :sb-cltl2)' \
        --eval '(asdf:make :foo)'

=>

fatal error encountered in SBCL pid 25248(tid 140737353910016):
can't load .core for different runtime, sorry
Welcome to LDB, a low-level debugger for the Lisp runtime environment. 
ldb>
Ehvince
  • 17,274
  • 7
  • 58
  • 79
  • Might be related to https://stackoverflow.com/q/39133421/124319 – coredump Apr 11 '18 at 07:35
  • Looks like it is. I set `SBCL_HOME` to `/usr/local/lib/sbcl/` or `…/contrib` and `require`d `sb-cltl2` before building the executable with no success. – Ehvince Apr 11 '18 at 14:10
  • Maybe there are different versions SBCL installed, or a core generated with a previous version? Not sure how to replicate this. – coredump Apr 11 '18 at 15:23
  • There's only one `which sbcl`… and one in roswell's path. However how can I check this core thing ? A quick search and manual overview didn't throw anything obvious. – Ehvince Apr 11 '18 at 16:05
  • Can you check the value of `(SB-INT:SBCL-HOMEDIR-PATHNAME)` in both environments? – coredump Apr 12 '18 at 07:52
  • 1
    @coredump in Slime: `#P"/usr//lib/sbcl/"` (and `14`) which is weird, in my main function: `#: The variable SB-INT:SBCL-HOMEDIR-PATHNAME is unbound.`. It seems I miss all the contribs. It's the first time it happens :/ – Ehvince Apr 12 '18 at 10:27
  • *The **variable** SB-INT:SBCL-HOMEDIR-PATHNAME is unbound*? maybe you did not call it as a function? Are you using Docker to setup the system? – coredump Apr 12 '18 at 11:46
  • damn sorry, it is `NIL`. No I am not using docker. Debian's SBCL 1.2.4. – Ehvince Apr 12 '18 at 12:16
  • 1
    Given the path `/usr/lib/sbcl/` under Slime, I would try to set `SBCL_HOME` to that value (location of SBCL installed by Apt?) instead of `/usr/local/lib/sbcl/` (the one installed by Ros?). – coredump Apr 12 '18 at 13:14
  • It works. In your answer would you expand a bit on your reasoning ? Thank you very much ! – Ehvince Apr 12 '18 at 13:48

2 Answers2

2

The following environment failed:

export SBCL_HOME=/usr/local/lib/sbcl/  

The error message tells us the following:

can't load .core for different runtime, sorry

Apparently the SBCL you ran used the given SBCL_HOME to find its core file, but failed due to the core being generated by different version SBCL. A quick look at SBCL's source (starting from require) shows that the underlying function #'SB-INT:SBCL-HOMEDIR-PATHNAME is called to determine the installation path.

It looks like the one installed from the Debian package was installed in /usr/lib/sbcl/. The core file was easily found when starting Slime. You also had another version of SBCL in ~/.roswell/, but I guess you also ran ros install which installed it under /usr/local/lib/sbcl (/usr/local/ is for software that is not managed by the system).

Starting the roswell one when setting SBCL_HOME to the directory of the Debian one provoked the error about the incompatible core file (I guess).

What remains suprising is that (SB-INT:SBCL-HOMEDIR-PATHNAME) returns nil when starting your main function.

coredump
  • 37,664
  • 5
  • 43
  • 77
0

In my case it was complaining about sb-concurrency. This was with a Clack/Woo combination. I was being told:

Don't know how to REQUIRE sb-concurrency

Thanks to this post and this related one, I solved the issue by explicitly depending on sb-concurrency within my .asd file. After that, I didn't need to do anything special in my source files; compiled executables "just worked" after that.

Colin Woodbury
  • 1,799
  • 2
  • 15
  • 25