Comment 3 for bug 1292845

Hello!

Thanks for finding a typo. Here is a new patch (diff from https://github.com/sbcl/sbcl/commit/4c0c126812cb113c2be522386bd93453c6317918) 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.
Status:
 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)
ok
//apparent success (reached end of run-tests.sh 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 <http://gnu.org/licenses/gpl.html>
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:
<http://bugs.dragonflybsd.org/>...
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/libpthread.so.0
(gdb) bt
#0 0x0000000800a84f1c in _umtx_wakeup_err () from /usr/lib/libpthread.so.0
Cannot access memory at address 0x802627f08
(gdb) info thread
  Id Target Id Frame
  2 process 172 0x0000000800a84f1c in _umtx_wakeup_err () from /usr/lib/libpthread.so.0
* 1 process 168 0x0000000800a84f1c in _umtx_wakeup_err () from /usr/lib/libpthread.so.0
(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 cannot return (0xc3) from _umtx_wakeup_err (which is a system call). It happens all the time. I do not know why. Bug in OS, probably