<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-14 20:50 GMT+04:00 Matthew Dillon <span dir="ltr"><<a href="mailto:dillon@apollo.backplane.com" target="_blank">dillon@apollo.backplane.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
:Hello. I use DragonFlyBSD on x86-64 machine:<br>
:<br>
:Fatal error 'Cannot allocate red zone for initial thread' at line 275 in<br>
<div class="">:file /usr/src/lib/libthread_xu/thread/thr_init.c (errno = 12)<br>
<br>
</div>    Hmm.  It sounds like the threading system is being started late.<br>
    What is happening is that the main program has already allocated stack<br>
    past the initial thread stack size before trying to start the pthreads<br>
    subsystem.  This is a lot of space... 2MB or so.  I don't know why it<br>
    is doing that.<br>
<br>
    Either that or some part of SBCL did some specific mmap()'s into<br>
    the user stack space which it should not have done.  It is one of those<br>
    two things.<br>
<br>
    Here is something to try real quick as a patch to libthread_xu.  It<br>
    requires DragonFly sources in /usr/src (if you haven't already) to test<br>
    this:<br>
<br>
        cd /usr/src/lib/libthread_xu<br>
<br>
        Change THR_STACK_INITIAL from THR_STACK_DEFAULT * 2 to<br>
        THR_STACK_DEFAULT * 4 in thread/thr_private.h.<br>
<br>
        Then recompile libthread_xu:<br>
<br>
        cd /usr/srclib/libthread_xu<br>
        make clean<br>
        make obj<br>
        make clean<br>
        make -j 4<br>
        make install<br>
<br>
    If that doesn't work then try * 8... I don't know how much stack lisp<br>
    is trying to use.  The default 2MB is already a lot.  So if it still<br>
    doesn't work then it must be trying to do specific mmap()'s into the<br>
    user stack area which the program should definitely not be doing.<br>
<br>
                                                    -Matt<br>
<br>
</blockquote></div><br></div><div class="gmail_extra">I finally found the problem! This happens when the library is loaded TWICE (one time at compile time, one time in load time in IOLIB) and calls dlclose between two dlopens. Here is a minimal test case in lisp:<br>
<br>(defpackage test<br>  (:use :cl :cffi))<br>(eval-when (:compile-toplevel :load-toplevel :execute)<br>  (define-foreign-library libfixposix<br>    (t (:default "libfixposix")))<br>  (use-foreign-library libfixposix))<br>
<br></div><div class="gmail_extra">and here is the same in C:<br><br>#include <dlfcn.h><br>#include <stdlib.h><br>#include <stdio.h><br><br>int main(int argc, char *argv[])<br>{<br>    printf ("testing %s\n", argv[1]);<br>
    void *handle = dlopen (argv[1], RTLD_NOW|RTLD_GLOBAL);<br>    if (handle == NULL)<br>    {<br>        fprintf (stderr, "Cannot open the library\n");<br></div><div class="gmail_extra">        exit (1);<br></div>
<div class="gmail_extra">    }<br>    dlclose(handle);<br>    void *handle2 = dlopen (argv[1], RTLD_NOW|RTLD_GLOBAL);<br>    return 0;<br>}<br><br></div><div class="gmail_extra">You can compile my program and try the following:<br>
</div><div class="gmail_extra">find /usr/local/lib -name "*.so" -exec ./test {} \;<br><br></div><div class="gmail_extra">You will see many of these errors not for all libraries, but for many of them. I cannot say by now why it does not work for all libraries.<br>
</div></div>