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

[Vasily Postnicov]

2014-04-14 14:37 GMT+04:00 John Marino <dragonflybsd at marino.st>:

> On 4/14/2014 12:15, Vasily Postnicov wrote:
> > 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.
>
>
> There has been a few attempts to patch the sbcl in ports to get it to
> work on DragonFly and they got close but never quite succeeded.  If you
> do succeed, there are two routes you can take:
>
> 1) give me the patches so I can get it into dports
> 2) (better) give the patches upstream so sbcl builds out-of-the-box on
> dragonfly.
>
> unfortunately I can't help you with your immediately issue.  I think
> there are some lisp-lovers in dragonfly community though that might be
> better qualified to assist.
>
> John
>

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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20140414/0fc42971/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patches.tar
Type: application/x-tar
Size: 50176 bytes
Desc: not available
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20140414/0fc42971/attachment-0002.tar>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sbcl.patch
Type: text/x-patch
Size: 29678 bytes
Desc: not available
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20140414/0fc42971/attachment-0002.bin>