[Ecls-list] [usocket-devel] ECL support

Marko Kocić marko.kocic at gmail.com
Tue Feb 16 17:10:17 UTC 2010


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 at 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
>




More information about the ecl-devel mailing list