On OS X, with SLIME, inferior lisp stopped when loading foreign libraries

2
votes

I use Quicklisp to load systems, and I debug my code with Slime. Quicklisp loads many systems successfully except cl-postgresql.

When evaluating (ql:quickload "clsql-postgresql") in slime, the inferior lisp exits.

Slime prints

Lisp connection closed unexpectedly: connection broken by remote peer

in minibuffer and

Process inferior-lisp trace/BPT trap: 5

in *inferior-lisp* buffer.

But evaluating (ql:quickload "clsql-postgresql") in SBCL without Slime won't cause any error.

I have searched "trace/BPT trap: 5" with Google. The message seems indicating problems in loading dynamic libraries. I suppose the error is caused by wrong search paths set by Slime. According to http://clsql.b9.com/manual/appendix.html, I checked CLSQL:*FOREIGN-LIBRARY-SEARCH-PATHS* in bare SBCL and Slime environment, but they were both nil.

Why did clsql-postgresql fail to be load when using Slime?

Environment:

  • SBCL 1.1.8
  • OS X 10.8.4
  • latest quicklisp
  • latest slime
  • emacs 24.3

(sorry for my English, I'm not a native speaker)

1
common-lispffislimequicklispclsql

1 Answers

0
votes

I checked User Diagnostic Report. And I found the following lines:

Thread 7 Crashed:
0   com.apple.CoreFoundation        0x00007fff8fab52d5 __CFInitialize + 69
1   dyld                            0x00007fff6f56d256

So I googled "CoreFoundation". It said that CoreFoundation must be loaded by the main thread, otherwise it would signal SIGTRAP. It's a rule of OS X.

See: Debugging a crash when a library is opened via dlopen on OSX

In bare SBCL, ql:quickload is directly evaluated in the main thread. But under SLIME, forms are evaluated with a separated thread started by SWANK.

The solution is to evaluate (ql:quickload "clsql-postgresql") in *inferior-lisp*, instead of *slime-repl*, when libpg is the first foreign library depending on CoreFoundation to be loaded.