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

[Vasily Postnicov]

2014-04-14 20:50 GMT+04:00 Matthew Dillon <dillon at apollo.backplane.com>:

>
> :Hello. I use DragonFlyBSD on x86-64 machine:
> :
> :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)
>
>     Hmm.  It sounds like the threading system is being started late.
>     What is happening is that the main program has already allocated stack
>     past the initial thread stack size before trying to start the pthreads
>     subsystem.  This is a lot of space... 2MB or so.  I don't know why it
>     is doing that.
>
>     Either that or some part of SBCL did some specific mmap()'s into
>     the user stack space which it should not have done.  It is one of those
>     two things.
>
>     Here is something to try real quick as a patch to libthread_xu.  It
>     requires DragonFly sources in /usr/src (if you haven't already) to test
>     this:
>
>         cd /usr/src/lib/libthread_xu
>
>         Change THR_STACK_INITIAL from THR_STACK_DEFAULT * 2 to
>         THR_STACK_DEFAULT * 4 in thread/thr_private.h.
>
>         Then recompile libthread_xu:
>
>         cd /usr/srclib/libthread_xu
>         make clean
>         make obj
>         make clean
>         make -j 4
>         make install
>
>     If that doesn't work then try * 8... I don't know how much stack lisp
>     is trying to use.  The default 2MB is already a lot.  So if it still
>     doesn't work then it must be trying to do specific mmap()'s into the
>     user stack area which the program should definitely not be doing.
>
>                                                     -Matt
>
>
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:

os_vm_address_t
os_validate(os_vm_address_t addr, os_vm_size_t len)
{
    int flags = MAP_PRIVATE | MAP_ANON;

    if (addr)
        flags |= MAP_TRYFIXED;

    addr = mmap(addr, len, OS_VM_PROT_ALL, flags, -1, 0);

    if (addr == MAP_FAILED) {
        perror("mmap");
        return NULL;
    }
    printf ("====== OS_VALIDATE: allocated %li bytes at 0x%08lx ======\n",
len, addr);
    return addr;
}

Here is the output:
http://pastebin.com/n4Bng5MJ

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20140415/3bd35c55/attachment-0003.htm>