Can anyone help to shed the light on mysterious bug in SBCL (probably)?

[Vasily Postnicov]

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
vasily at cyberspace.cyberspace:/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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20140414/d5c14c31/attachment.html>