Can anyone help to shed the light on mysterious bug in SBCL (probably)?
Vasily Postnicov
shamaz.mazum at gmail.com
Mon Apr 14 03:15:01 PDT 2014
Hello. I use DragonFlyBSD on x86-64 machine:
uname -a
DragonFly cyberspace.cyberspace 3.6-RELEASE DragonFly
v3.6.2.2.g063e0-RELEASE #7: Sun Apr 13 09:50:36 MSK 2014
vasily at cyberspace.cyberspace:/usr/obj/usr/src/sys/MYKERNEL
x86_64
I use Common Lisp for my programming tasks and my favorite implementation
of CL is SBCL. There is no official port of SBCL on DragonFly, so I keep my
own repo for it:
https://github.com/shamazmazum/sbcl-dragonfly
I've encountered a strange bug recently when tried to compile IOLib (
http://common-lisp.net/project/iolib/). IOLib uses its own C library,
called libfixposix. SBCL (v1.1.17) loads it calling dlopen through FFI
interface. For some reason it does it at compile time:
(eval-when (:compile-toplevel :load-toplevel :execute)
(define-foreign-library libfixposix
(t (:default "libfixposix")))
(use-foreign-library libfixposix)) ; Calls sb-alien::dlopen
So I get this when try to compile/load IOLib (with asdf:load-system :iolib):
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)
fatal error encountered in SBCL pid 5888:
SIGABRT received.
More output (with backtrace):
http://pastebin.com/LSJ2s8MG
The code responsible for creating the red zone (which is a stack guard
page, as I understand it):
if (mmap(_usrstack - _thr_stack_initial -
_thr_guard_default, _thr_guard_default,
0, MAP_ANON | MAP_TRYFIXED, -1, 0) == MAP_FAILED) {
PANIC("Cannot allocate red zone for initial thread");
}
It happens every time when I compile IOLib from scratch (with all .fasl
files from previous compilation removed). It also appears both on x86-64
and x86.
When I remove eval-when block and place define/use-foreign-library on
toplevel (preventing libfixposix from being loaded at compile time), IOLib
builds normally and works just fine. The same happens when I load SBCL like
this:
LD_PRELOAD=/usr/lib/thread/libthread_xu.so sbcl
I cannot understand why this is happening, because C stack is growing
backward from 0x800000000000 (Fix me if I am not right) and SBCL control
stack is here (look at pastebin):
CSP = 0x800fd4ae8
And SBCL's heap starts at 0x1000000000 and has size 1Gb (as set in
sbcl/src/compiler/x86-64/parms.lisp) so it cannot be that any of those
spaces intersect. Unfortunately, /proc/<sbcl_pid>/map file is empty, so I
cannot say for sure.
Can anyone share an idea what to do? I have no idea how to debug such
complicated program as SBCL is. I am writing here because there are no
DragonFly users among SBCL developers, as it seems.
With best regards, Vasily.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20140414/d5c14c31/attachment-0002.htm>
More information about the Users
mailing list