load-shared-object crash on #+(and :sb-thread :darwin)

[Ole Rohne]

SBCL on Darwin crashes when trying to load certain shared library.
Test case: (load-shared-object #p"/usr/local/lib/libaquaterm.dylib")
From google it seems that dlopen/__CFInitialize must only be called from the main thread. Patch below seems to fix the issue.

$ sbcl --version
SBCL 1.0.57.29.merged.28-0e35fce

$ uname -a
Darwin pb-d-128-141-226-70.cern.ch 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

* *features*
(:QUICKLISP :ASDF2 :ASDF :ASDF-UNICODE :SB-THREAD :ANSI-CL :COMMON-LISP :SBCL
 :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE :SB-EVAL
 :SB-SOURCE-LOCATIONS :IEEE-FLOATING-POINT :OS-PROVIDES-SUSECONDS-T
 :OS-PROVIDES-BLKSIZE-T :OS-PROVIDES-PUTWC :OS-PROVIDES-DLADDR
 :OS-PROVIDES-DLOPEN :LITTLE-ENDIAN :MULTIPLY-HIGH-VOPS :MEMORY-BARRIER-VOPS
 :INLINE-CONSTANTS :FLOAT-EQL-VOPS :COMPLEX-FLOAT-VOPS :CYCLE-COUNTER
 :ALIEN-CALLBACKS :STACK-ALLOCATABLE-FIXED-OBJECTS :STACK-ALLOCATABLE-LISTS
 :STACK-ALLOCATABLE-VECTORS :STACK-ALLOCATABLE-CLOSURES :RAW-INSTANCE-INIT-VOPS
 :UNWIND-TO-FRAME-AND-CALL-VOP :COMPARE-AND-SWAP-VOPS :LINKAGE-TABLE
 :C-STACK-IS-CONTROL-STACK :STACK-GROWS-DOWNWARD-NOT-UPWARD :GENCGC
 :UD2-BREAKPOINTS :MACH-EXCEPTION-HANDLER :DARWIN :BSD :MACH-O :UNIX
 :DARWIN9-OR-BETTER :INODE64 :X86-64)

Excerpt from ~/Library/Logs/DiagnosticReports/

Process: sbcl [16293]
Path: /usr/local/bin/sbcl
Identifier: sbcl
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: Emacs [14491]

Date/Time: 2012-06-17 21:16:14.255 +0200
OS Version: Mac OS X 10.6.8 (10K549)
Report Version: 6

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread: 7

(...)

Thread 7 Crashed:
0 com.apple.CoreFoundation 0x00007fff88285590 __CFInitialize + 1808
1 dyld 0x00007fff5fc0d5ce ImageLoaderMachO::doImageInit(ImageLoader::LinkContext const&) + 138
2 dyld 0x00007fff5fc0d607 ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 27
3 dyld 0x00007fff5fc0bcec ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int) + 236
4 dyld 0x00007fff5fc0bc9d ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int) + 157
5 dyld 0x00007fff5fc0bc9d ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int) + 157
6 dyld 0x00007fff5fc0bda6 ImageLoader::runInitializers(ImageLoader::LinkContext const&) + 58
7 dyld 0x00007fff5fc08fbb dlopen + 573

[Paul Khuong (pvk)]

Interrupting the main thread is most emphatically *not* a good idea, least of all in the standard runtime. There has been some talk of reserving the main thread for book keeping tasks like loading shared libraries, but nothing concrete. In the meantime, I suggest you just load the library from the bare REPL (i.e. *inferior-lisp* in SLIME).

[Nikodemus Siivola (nikodemus)]

Or load it in .sbclrc.

Or save a core with the .so loaded: reloading shared libs happens in the main thread.

Or use --eval '(load-shared-object "foo.so")' on the commandline.