From: Harald Hanche-O. <ha...@ma...> - 2009-03-19 12:28:51
|
+ Gábor Melis <me...@re...>: > Could you try this patch, rebuild and run the tests, please? Done. During the build, I get the same error as before when building asdf-install. For the test, this time I get nothing at all when I try getting a backtrace from the ldb> prompt. The stderr output from my test is at http://www.math.ntnu.no/~hanche/tmp/sbcl-test2-stderr.txt and here is the terminal session. >[2] is how I redirect stderr in my shell (es). temp.pure.lisp is interface.pure.lisp with everything other than the :with-timeout-forms test ripped out. ; sh run-tests.sh temp.pure.lisp >[2] /dev/ttys000 /running tests on '/local/src/lisp/sbcl/sbcl-git/tests/../src/runtime/sbcl --core /local/src/lisp/sbcl/sbcl-git/tests/../output/sbcl.core --noinform --no-sysinit --no-userinit --noprint' ; loading system definition from ; /local/src/lisp/sbcl/sbcl-git/contrib/sb-posix/sb-posix.asd into ; #<PACKAGE "ASDF0"> ; loading system definition from ; /local/src/lisp/sbcl/sbcl-git/contrib/sb-grovel/sb-grovel.asd into ; #<PACKAGE "ASDF1"> ; registering #<SYSTEM SB-GROVEL {12083CC9}> as SB-GROVEL ; registering #<SYSTEM SB-POSIX {12653889}> as SB-POSIX ; registering #<SYSTEM SB-POSIX-TESTS {12780CA9}> as SB-POSIX-TESTS // Running pure tests (#<FUNCTION RUN-TESTS::LOAD-TEST>) // Running /local/src/lisp/sbcl/sbcl-git/tests/temp.pure.lisp ::: Running :WITH-TIMEOUT-FORMS Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> ba Backtrace: ::: UNEXPECTED-FAILURE :WITH-TIMEOUT-FORMS // Running pure tests (#<FUNCTION RUN-TESTS::CLOAD-TEST>) // Running impure tests (#<FUNCTION RUN-TESTS::LOAD-TEST>) // Running impure tests (#<FUNCTION RUN-TESTS::CLOAD-TEST>) // Running impure tests (#<FUNCTION RUN-TESTS::SH-TEST>) Finished running tests. Status: Failure: temp.pure.lisp / WITH-TIMEOUT-FORMS test failed, expected 104 return code, got 1 Here is my (lightly edited) gdb session. I attached to the lisp while it was waiting on the ldb> prompt. ; gdb /local/src/lisp/sbcl/sbcl-git/src/runtime/sbcl 2975 GNU gdb 6.3.50-20050815 (Apple version gdb-768) (Tue Oct 2 04:11:19 UTC 2007) This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared libraries ... done Attaching to program: `/local/src/lisp/sbcl/sbcl-git/src/runtime/sbcl', process 2975. Reading symbols for shared libraries ++. done 0x95f7ce0c in read$NOCANCEL$UNIX2003 () (gdb) ba #0 0x95f7ce0c in read$NOCANCEL$UNIX2003 () #1 0x95fc6144 in _sread () #2 0x95fc60b0 in __srefill () #3 0x95fc5e2c in fgets () #4 0x00009fd0 in ldb_monitor () at monitor.c:466 #5 0x00007308 in lose (fmt=0x18efc "deferrable signal %d blocked\n") at interr.c:71 #6 0x000074a8 in check_deferrables_unblocked_in_sigset_or_lose (sigset=0x7) at interrupt.c:221 #7 0x00007d90 in check_interrupt_context_or_lose (context=<value temporarily unavailable, due to optimizations>) at interrupt.c:413 #8 0x00009048 in maybe_defer_handler (handler=0x9560, data=0x37000, signal=14, info=0xbfff72e8, context=0xbfff7328) at interrupt.c:984 #9 0x000098d4 in maybe_now_maybe_later (signal=14, info=0xbfff72e8, void_context=0xbfff7328) at interrupt.c:1059 #10 <signal handler called> warning: unrecognized length (0x1000720) for sigtramp context #11 <signal handler called> warning: unrecognized length (0x1000720) for sigtramp context Previous frame identical to this frame (gdb could not unwind past this frame) (gdb) cont Continuing. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000280 code_pointer (object=<value temporarily unavailable, due to optimizations>) at backtrace.c:87 87 header = *headerp; (gdb) cont Continuing. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000280 code_pointer (object=<value temporarily unavailable, due to optimizations>) at backtrace.c:87 87 header = *headerp; (gdb) The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: `/local/src/lisp/sbcl/sbcl-git/src/runtime/sbcl', process 2975 thread 0x10b. I thought the lack of a backtrace in ldb was due to an interaction with gdb, but repeating the test without gdb produced the same result. - Harald |