Hello. I use DragonFlyBSD on x86-64 machine: uname -a DragonFly cyberspace.cyberspace 3.6-RELEASE DragonFly v3.6.2.2.g063e0-RELEASE #7: Sun Apr 13 09:50:36 MSK 2014 [email protected]:/usr/obj/usr/src/sys/MYKERNEL x86_64
I use Common Lisp for my programming tasks and my favorite implementation of CL is SBCL. There is no official port of SBCL on DragonFly, so I keep my own repo for it: https://github.com/shamazmazum/sbcl-dragonfly I've encountered a strange bug recently when tried to compile IOLib ( http://common-lisp.net/project/iolib/). IOLib uses its own C library, called libfixposix. SBCL (v1.1.17) loads it calling dlopen through FFI interface. For some reason it does it at compile time: (eval-when (:compile-toplevel :load-toplevel :execute) (define-foreign-library libfixposix (t (:default "libfixposix"))) (use-foreign-library libfixposix)) ; Calls sb-alien::dlopen So I get this when try to compile/load IOLib (with asdf:load-system :iolib): Fatal error 'Cannot allocate red zone for initial thread' at line 275 in file /usr/src/lib/libthread_xu/thread/thr_init.c (errno = 12) fatal error encountered in SBCL pid 5888: SIGABRT received. More output (with backtrace): http://pastebin.com/LSJ2s8MG The code responsible for creating the red zone (which is a stack guard page, as I understand it): if (mmap(_usrstack - _thr_stack_initial - _thr_guard_default, _thr_guard_default, 0, MAP_ANON | MAP_TRYFIXED, -1, 0) == MAP_FAILED) { PANIC("Cannot allocate red zone for initial thread"); } It happens every time when I compile IOLib from scratch (with all .fasl files from previous compilation removed). It also appears both on x86-64 and x86. When I remove eval-when block and place define/use-foreign-library on toplevel (preventing libfixposix from being loaded at compile time), IOLib builds normally and works just fine. The same happens when I load SBCL like this: LD_PRELOAD=/usr/lib/thread/libthread_xu.so sbcl I cannot understand why this is happening, because C stack is growing backward from 0x800000000000 (Fix me if I am not right) and SBCL control stack is here (look at pastebin): CSP = 0x800fd4ae8 And SBCL's heap starts at 0x1000000000 and has size 1Gb (as set in sbcl/src/compiler/x86-64/parms.lisp) so it cannot be that any of those spaces intersect. Unfortunately, /proc/<sbcl_pid>/map file is empty, so I cannot say for sure. Can anyone share an idea what to do? I have no idea how to debug such complicated program as SBCL is. I am writing here because there are no DragonFly users among SBCL developers, as it seems. With best regards, Vasily.
