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

[John Marino]

On 4/14/2014 12:15, Vasily Postnicov wrote:
> 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.


There has been a few attempts to patch the sbcl in ports to get it to
work on DragonFly and they got close but never quite succeeded.  If you
do succeed, there are two routes you can take:

1) give me the patches so I can get it into dports
2) (better) give the patches upstream so sbcl builds out-of-the-box on
dragonfly.

unfortunately I can't help you with your immediately issue.  I think
there are some lisp-lovers in dragonfly community though that might be
better qualified to assist.

John