CC-ing ecl-list since this might look similar to problems that ecl git currenty have with new slime.
You can see backtrace by attaching gdb to ecl process. You do something like: pgrep ecl gdb ~/bin/ecl ecl_pid
Right now I'm getting this backtrace while running hunchentoot-tests.
(gdb) bt #0 0x00007f8c73f05a6b in read () from /lib/libc.so.6 #1 0x00007f8c73ea5ad8 in _IO_file_underflow () from /lib/libc.so.6 #2 0x00007f8c73ea54a8 in ?? () from /lib/libc.so.6 #3 0x00007f8c73e9b312 in fread () from /lib/libc.so.6 #4 0x00007f8c74968f9b in fread (strm=0x5192e60, c=0x7fffb2b958ef "", n=1) at /usr/include/bits/stdio2.h:287 #5 input_stream_read_byte8 (strm=0x5192e60, c=0x7fffb2b958ef "", n=1) at /home/markko/cvstree/ecl.git/src/c/file.d:3215 #6 0x00007f8c74968805 in generic_read_byte_unsigned8 (strm=0x4) at /home/markko/cvstree/ecl.git/src/c/file.d:321 #7 0x00007f8c74971f13 in cl_read_byte (narg=3, binary_input_stream=0x5192d20) at /home/markko/cvstree/ecl.git/src/c/read.d:1838 #8 0x00007f8c6987efdd in LC12stream_read_byte (V1=0x6b405d0) at /home/markko/.fasls/ecl-10.2.1-linux-x86-64/home/markko/.cache/common-lisp/ecl-10.2.1-linux-x86-64/home/markko/cvstree/clbuild/source/chunga/input.c:338 #9 0x00007f8c7495ac3f in cl_apply (narg=2, fun=0x47fd7c0, lastarg=0x7fffb2b95d40) at /home/markko/cvstree/ecl.git/src/c/eval.d:138 #10 0x00007f8c7490c0dd in LC2__g4 (narg=<value optimized out>, V1=<value optimized out>, V2=0x6c093d1) at /home/markko/cvstree/ecl.git/build/clos/combin.c:117 #11 0x00007f8c7490bf37 in LC4__g5 (narg=<value optimized out>, V1=0x7fffb2b95d40, V2=<value optimized out>) at /home/markko/cvstree/ecl.git/build/clos/combin.c:149
On Tue, Feb 16, 2010 at 10:53 AM, Marko Kocić marko.kocic@gmail.com wrote:
Yes, the problem was similar.
After updating ECL from git, it seems it behaves differently now. When I try hunchentoot test it just waits and does nothing.
Regards, Marko