<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>