From: Gábor M. <me...@re...> - 2009-03-16 17:34:20
|
On Sábado 14 Marzo 2009, Harald Hanche-Olsen wrote: > I can build sbcl from the latest source, but at the end I am told > > WARNING! Some of the contrib modules did not build successfully or > pass their self-tests. Failed contribs:" > asdf-install > sb-bsd-sockets > > > And indeed, the asdf-install build ends thusly: > > ; SYS:CONTRIB;SB-BSD-SOCKETS;SPLIT.FASL.NEWEST written > ; compilation finished in 0:00:00.095 > (SYS:CONTRIB;SB-BSD-SOCKETS;CONSTANTS.LISP.NEWEST > SYS:CONTRIB;SB-BSD-SOCKETS;CONSTANTS.FASL.NEWEST > /local/src/lisp/sbcl/sbcl-git/contrib/sb-bsd-sockets/constants.fasl > /local/src/lisp/sbcl/sbcl-git/contrib/sb-bsd-sockets/foo.c > /local/src/lisp/sbcl/sbcl-git/contrib/sb-bsd-sockets/a.out > > /local/src/lisp/sbcl/sbcl-git/contrib/sb-bsd-sockets/constants.lisp-t >emp) fatal error encountered in SBCL pid 77761: > deferrable signal 1 blocked > > > whereas the sb-bsd-sockets builds ends on a seemingly unrelated > problem: > > unhandled SB-INT:SIMPLE-FILE-ERROR: > failed to find the TRUENAME of > /local/src/lisp/sbcl/sbcl-git/contrib/sb-posix/constants.lisp-temp: > No such file or directory > > > and finally, testing ends here: > > // Running /local/src/lisp/sbcl/sbcl-git/tests/interface.pure.lisp > #0A0 is an array of dimension (). > #(1 2 3) is a vector with 3 elements. > #2A((1 2) (3 4)) is an array of dimension (2 2). > > ::: Running :WITH-TIMEOUT-FORMS > > fatal error encountered in SBCL pid 84201: > deferrable signal 1 blocked > > (and no more tests are run). > > And no, I checked, and I see no indication that I am doing anything > to block signal 1. > > - Harald I wrote a section that may go into BUGS later on what's needed to diagnose these bugs. I guess, your test case is just: (handler-bind ((sb-ext:timeout #'continue)) (sb-ext:with-timeout 3 (sleep 2) (sleep 2))) Cheers, Gabor ------------------------------------- If you run into a signal related bug, you are getting fatal errors such as 'signal N is [un]blocked' or just hangs, and you want to send a useful bug report then: 1) compile sbcl with ldb support (feature :sb-ldb, see base-target-features.lisp-expr) and with QSHOW, QSHOW_SAFE and QSHOW_SIGNAL: diff --git a/src/runtime/runtime.h b/src/runtime/runtime.h index 01f4031..836ebfa 100644 --- a/src/runtime/runtime.h +++ b/src/runtime/runtime.h @@ -29,8 +29,8 @@ #define thread_mutex_unlock(l) 0 #endif -/* #define QSHOW */ /* Enable low-level debugging output? */ -/* #define QSHOW_SAFE */ /* Enable blocking interrupts for each SHOW. */ +#define QSHOW /* Enable low-level debugging output? */ +#define QSHOW_SAFE /* Enable blocking interrupts for each SHOW. */ #ifdef QSHOW @@ -80,7 +80,7 @@ extern sigset_t blockable_sigset; * necessarily reentrant. But it can still be very convenient for * figuring out what's going on when you have a signal handling * problem.. */ -#define QSHOW_SIGNALS 0 +#define QSHOW_SIGNALS 1 #if QSHOW_SIGNALS #define FSHOW_SIGNAL FSHOW 2) isolate a smallish test case, run it 3) if it just hangs kill it with sigabrt: kill -ABRT <pidof sbcl> 4) print the backtrace from ldb by typing 'ba' 5) attach gdb: gdb -p <pidof sbcl> and get backtraces for all threads: thread apply all ba 6) if multiple threads are in play then still in gdb, try to get Lisp backtrace for all threads: 'thread apply all call_backtrace_from_fp($ebp, 100)'. Substitute $ebp with $rbp on x86-64. 7) send a report with the backtraces and the output (both stdout, stderr) produced by sbcl 8) don't forget to include OS and SBCL version |