<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">Hello, Matt. I've tried to increase the stack size as you said (multiplying by 4, 8 and even 512), but no luck. SBCL allocates memory for lisp objects by calling to os_validate which is a wrapper around mmap. I modified it to be more verbose:<br>
<br>os_vm_address_t<br>os_validate(os_vm_address_t addr, os_vm_size_t len)<br>{<br>    int flags = MAP_PRIVATE | MAP_ANON;<br><br>    if (addr)<br>        flags |= MAP_TRYFIXED;<br><br>    addr = mmap(addr, len, OS_VM_PROT_ALL, flags, -1, 0);<br>
<br>    if (addr == MAP_FAILED) {<br>        perror("mmap");<br>        return NULL;<br>    }<br>    printf ("====== OS_VALIDATE: allocated %li bytes at 0x%08lx ======\n", len, addr);<br>    return addr;<br>
}<br><br></div><div class="gmail_extra">Here is the output:<br><a href="http://pastebin.com/n4Bng5MJ">http://pastebin.com/n4Bng5MJ</a><br><br></div><div class="gmail_extra">The minimal mapped address is 0x20000000 which is a beginning of lisp "readonly and static" spaces (sbcl/src/compiler/generic/parms.lisp), the maximal address is 0x100a818000 which is a lisp heap. There is another region starting at 0x80067c000 which is a lisp stack (it has its own), according to LDB (built-in SBCL debugger). So, as it seems,  SBCL does not interfere with C stack. I think ktrace may be helpful, I will write if I find something.<br>
</div></div>