Support for DragonFlyBSD

Bug #1292845 reported by Vasily Postnicov on 2014-03-15
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

This is not a bug, actually, but a wish.

So my wish is to see sbcl working on DragonFly BSD. I attach a patch which makes it possible. The only problem I have met is multithreading. I do not know how to implement multithreading on x86 properly (because there is difference in some system calls between DragonFly BSD and FreeBSD from which DragonFly was forked and it's to complicate for me). On x86-64 multithreading is available but very unstable when many threads are created and deleted (and maybe we cannot do anything with it, see

When built without sb-thread, sbcl passes all tests (with exception 4 "expect failures") on x86-64 and fails one test ((sleep :non-consing) in interface.pure.lisp) on x86.

Vasily Postnicov (shamaz-mazum) wrote :
Stas Boukarev (stassats) on 2014-03-16
tags: added: review
Changed in sbcl:
importance: Undecided → Wishlist
status: New → Triaged


The patch probably doesn't apply any more, thanks to other *BSD updates. I can manually fix it up, but I wonder if you (the original reporter) have made any progress on it since the original submission?

+ DragonFly-X84) new=-fPIC ;;

should this be DragonFly-X86?

The patch otherwise looks reasonable, modulo the uncertainties about threads. How can we best support investigation and development of this issue?

Vasily Postnicov (shamaz-mazum) wrote :
Download full text (3.3 KiB)


Thanks for finding a typo. Here is a new patch (diff from tested with DragonFly 3.8 x86-64. Unfortunately, I do not have x86 machine by now to test on that architecture.

Test results (hand typed ;):

Finished running tests.
 Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET
 Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT
 Expected failure: walk.impure.lisp / (WALK-LET* HAIRY-SPECIALS)
 Expected failure: walk.impure.lisp / (WALK-LET* HAIRY-SPECIALS)
 (51 tests skipped for this combination of platform and features)
//apparent success (reached end of normally)
Tue Jun 17 19:42:15 MSK 2014

Please, do not worry that #define CREATE_POST_MORTEM_THREAD was removed, it is useless anyway.

As for threads, I have no idea, what to do. SBCL can be compiled with sb-thread on x86-64, but it will randomly crash while using this functionality.

I have this in GDB:

gdb ../src/runtime/sbcl sbcl.core
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-dragonfly".
For bug reporting instructions, please see:
Reading symbols from /home/vasily/sbcl-dragonfly/src/runtime/sbcl...done.
BFD: Warning: /home/vasily/sbcl-dragonfly/tests/sbcl.core is truncated: expected core file size >= 1072648192, found: 152567808.
[New process 168]
[New process 172]
Core was generated by `sbcl'.
Program terminated with signal 4, Illegal instruction.
#0 0x0000000800a84f1c in _umtx_wakeup_err () from /usr/lib/
(gdb) bt
#0 0x0000000800a84f1c in _umtx_wakeup_err () from /usr/lib/
Cannot access memory at address 0x802627f08
(gdb) info thread
  Id Target Id Frame
  2 process 172 0x0000000800a84f1c in _umtx_wakeup_err () from /usr/lib/
* 1 process 168 0x0000000800a84f1c in _umtx_wakeup_err () from /usr/lib/
(gdb) info reg
rax 0x0 0
rbx 0x8006904e0 34366620896
rcx 0x802627f08 34399747848
rdx 0x80296fa00 34403187200
rsi 0x80296ff80 34403188608
rdi 0xb 11
rbp 0x802627f10 0x802627f10
rsp 0x802627f08 0x802627f08
r8 0x240 576
r9 0xffffffe098291380 -134886124672
r10 0x1 1
r11 0x20100017 537919511
r12 0x8006904e0 34366620896
r13 0x8006904f8 34366620920
r14 0x0 0
r15 0x8006900c0 34366619840
rip 0x800a84f1c 0x800a84f1c <_umtx_wakeup_err+12>
eflags 0x10206 [ PF IF RF ]
cs 0x2b 43
ss 0x23 35
ds *value not available*
es *value not available*
fs *value not available*
gs *value not available*
(gdb) x/1xb 0x800a84f1c
0x800a84f1c <_umtx_wakeup_err+12>: 0xc3

It means it ...


Changed in sbcl:
status: Triaged → Fix Committed
Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers