<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-14 14:37 GMT+04:00 John Marino <span dir="ltr"><<a href="mailto:dragonflybsd@marino.st" target="_blank">dragonflybsd@marino.st</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 4/14/2014 12:15, Vasily Postnicov wrote:<br>
> Hello. I use DragonFlyBSD on x86-64 machine:<br>
><br>
> uname -a<br>
> DragonFly cyberspace.cyberspace 3.6-RELEASE DragonFly<br>
> v3.6.2.2.g063e0-RELEASE #7: Sun Apr 13 09:50:36 MSK 2014<br>
> vasily@cyberspace.cyberspace:/usr/obj/usr/src/sys/MYKERNEL<br>
> x86_64<br>
><br>
> I use Common Lisp for my programming tasks and my favorite<br>
> implementation of CL is SBCL. There is no official port of SBCL on<br>
> DragonFly, so I keep my own repo for it:<br>
> <a href="https://github.com/shamazmazum/sbcl-dragonfly" target="_blank">https://github.com/shamazmazum/sbcl-dragonfly</a><br>
><br>
> I've encountered a strange bug recently when tried to compile IOLib<br>
> (<a href="http://common-lisp.net/project/iolib/" target="_blank">http://common-lisp.net/project/iolib/</a>). IOLib uses its own C library,<br>
> called libfixposix. SBCL (v1.1.17) loads it calling dlopen through FFI<br>
> interface. For some reason it does it at compile time:<br>
><br>
> (eval-when (:compile-toplevel :load-toplevel :execute)<br>
> (define-foreign-library libfixposix<br>
> (t (:default "libfixposix")))<br>
> (use-foreign-library libfixposix)) ; Calls sb-alien::dlopen<br>
><br>
> So I get this when try to compile/load IOLib (with asdf:load-system :iolib):<br>
><br>
> Fatal error 'Cannot allocate red zone for initial thread' at line 275 in<br>
> file /usr/src/lib/libthread_xu/thread/thr_init.c (errno = 12)<br>
><br>
><br>
> fatal error encountered in SBCL pid 5888:<br>
> SIGABRT received.<br>
><br>
> More output (with backtrace):<br>
> <a href="http://pastebin.com/LSJ2s8MG" target="_blank">http://pastebin.com/LSJ2s8MG</a><br>
><br>
> The code responsible for creating the red zone (which is a stack guard<br>
> page, as I understand it):<br>
> if (mmap(_usrstack - _thr_stack_initial -<br>
> _thr_guard_default, _thr_guard_default,<br>
> 0, MAP_ANON | MAP_TRYFIXED, -1, 0) == MAP_FAILED) {<br>
> PANIC("Cannot allocate red zone for initial thread");<br>
> }<br>
><br>
> It happens every time when I compile IOLib from scratch (with all .fasl<br>
> files from previous compilation removed). It also appears both on x86-64<br>
> and x86.<br>
><br>
> When I remove eval-when block and place define/use-foreign-library on<br>
> toplevel (preventing libfixposix from being loaded at compile time),<br>
> IOLib builds normally and works just fine. The same happens when I load<br>
> SBCL like this:<br>
><br>
> LD_PRELOAD=/usr/lib/thread/libthread_xu.so sbcl<br>
><br>
> I cannot understand why this is happening, because C stack is growing<br>
> backward from 0x800000000000 (Fix me if I am not right) and SBCL control<br>
> stack is here (look at pastebin):<br>
> CSP = 0x800fd4ae8<br>
><br>
> And SBCL's heap starts at 0x1000000000 and has size 1Gb (as set in<br>
> sbcl/src/compiler/x86-64/parms.lisp) so it cannot be that any of those<br>
> spaces intersect. Unfortunately, /proc/<sbcl_pid>/map file is empty, so<br>
> I cannot say for sure.<br>
><br>
> Can anyone share an idea what to do? I have no idea how to debug such<br>
> complicated program as SBCL is. I am writing here because there are no<br>
> DragonFly users among SBCL developers, as it seems.<br>
><br>
> With best regards, Vasily.<br>
<br>
<br>
</div></div>There has been a few attempts to patch the sbcl in ports to get it to<br>
work on DragonFly and they got close but never quite succeeded. If you<br>
do succeed, there are two routes you can take:<br>
<br>
1) give me the patches so I can get it into dports<br>
2) (better) give the patches upstream so sbcl builds out-of-the-box on<br>
dragonfly.<br>
<br>
unfortunately I can't help you with your immediately issue. I think<br>
there are some lisp-lovers in dragonfly community though that might be<br>
better qualified to assist.<br>
<span class="HOEnZb"><font color="#888888"><br>
John<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">1) I attach the patches (for sbcl-1.1.17) in tar archive - one patch for each file + one patch for all. Content is the same, of course. I hope I'm doing this right.<br>
</div><div class="gmail_extra">2) I've sent a patch to SBCL developers but they cannot accept it without testing and they cannot test it without DragonFly. Bah, this is too complicated.<br></div></div>