[Ecls-list] 10.3.1 slime issues

[Raffael Cavallaro]

On Mar 8, 2010, at 3:43 AM, Tobias C. Rittweiler wrote:

> cd ~/src/slime/
> ecl
> (load "swank-loader")
> (swank-loader:init)
> (swank:create-server)
> 
> (Now optionally, attach gdb. You can get the pid by (SI:GETPID), but you
> have to do it before creating the server because the server will occupy
> the main thread. 
> 
> In gdb you may have to ignore some signals, on Linux it's SIGPWR and
> SIGXCPU which are used by the boehm-gc; do not know about Mac, but
> that's Juanjo's development platform, too, so he'll probably know.
> 
> Also build ECL with --with-debug-cflags so the C backtraces will be nice.)

I rebuilt ecl with --with-debug-cflags

I started ecl in the slime directory.

(gdb) file ecl
(gdb) handle SIGPWR noprint nostop
(gdb) handle SIGXCPU noprint nostop
(gdb) attach ecl
(gdb) continue

I executed:
(load "swank-loader")
which resulted in ecl printing:

;;; Loading #P"/Users/raffaelc/Library/slime/swank-loader.lisp"

and hanging.

gdb printed:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f9d220
0x0000000100123f36 in _ecl_sethash_pack (key=0x1006500c0, hashtable=0x103f4d4e0, value=0x10317b200) at hash.d:401
401		HASH_TABLE_SET(h, _ecl_hash_loop_pack, _hash_equal(3, 0, key), MAKE_FIXNUM(h & 0xFFFFFFF));


continuing in gdb gives the same exc_bad_access.

If I attach to ecl *after* starting the swank-server, (and also handling  SIGPWR and SIGXCPU), then launch emacs, M-x slime-connect RET RET RET, I get another EXC_BAD_ACCESS.

the backtrace is below:

(gdb) backtrace
#0  0x0000000100137bb4 in GC_grow_table (table=0x1001d5290, log_size_ptr=0x1001d48b8) at /Users/raffaelc/Developer/lisp/ecl/src/gc/finalize.c:130
#1  0x0000000100137de1 in GC_register_finalizer_inner (obj=0x100d67000, fn=0x100131400 <queueing_finalizer>, cd=0x1001bc718, ofn=0x7fff5fbfcf88, ocd=0x7fff5fbfcf80, mp=0x100136d70 <GC_null_finalize_mark_proc>) at /Users/raffaelc/Developer/lisp/ecl/src/gc/finalize.c:322
#2  0x0000000100130f55 in ecl_set_finalizer_unprotected (o=<value temporarily unavailable, due to optimizations>, finalizer=<value temporarily unavailable, due to optimizations>) at alloc_2.d:1142
#3  0x0000000100130fb3 in si_set_finalizer (o=0x100d67000, finalizer=0x1001bc718) at alloc_2.d:1152
#4  0x000000010011e6ba in ecl_new_binding_index [inlined] () at /Users/raffaelc/Developer/lisp/ecl/src/c/stacks.d:266
#5  0x000000010011e6ba in invalid_or_too_large_binding_index (env=0x1003d1000, s=0x100d67000) at stacks.d:288
#6  0x000000010011e865 in ecl_bds_bind (env=0x1003d1000, s=0x100d67000, v=0x1) at stacks.d:311
#7  0x0000000103f4d911 in L33call_with_connection ()
#8  0x0000000103f37e21 in L166simple_serve_requests ()
#9  0x0000000103f0f5cd in L66serve_requests ()
#10 0x0000000103f383e1 in L63serve_connection ()
#11 0x0000000103f147c5 in LC54serve ()
#12 0x0000000103f36672 in L59setup_server ()
#13 0x0000000103f30cd3 in L52create_server ()
#14 0x00000001000db392 in ecl_interpret (frame=0x7fff5fbfdc80, env=0x1, bytecodes=0x10324f820) at interpreter.d:499
#15 0x00000001000df16b in si_eval_with_env (narg=<value temporarily unavailable, due to optimizations>, form=0x10372e6e1) at compiler.d:2867
#16 0x00000001000c3982 in LC19rep (narg=0) at /Users/raffaelc/Developer/lisp/ecl/build/clos/top.c:942
#17 0x00000001000c4d0d in L24tpl (narg=0) at /Users/raffaelc/Developer/lisp/ecl/build/clos/top.c:850
#18 0x00000001000c5fe9 in ecl_bds_unwind1_inl [inlined] () at /Users/raffaelc/Developer/lisp/ecl/build/ecl/stacks.h:42
#19 0x00000001000c5fe9 in L1top_level () at /Users/raffaelc/Developer/lisp/ecl/build/clos/top.c:43
#20 0x00000001000db458 in ecl_interpret (frame=0x7fff5fbfe2f0, env=0x1, bytecodes=0x102c466e0) at interpreter.d:491
#21 0x00000001000df16b in si_eval_with_env (narg=<value temporarily unavailable, due to optimizations>, form=0x102ca64d1) at compiler.d:2867
#22 0x00000001000bd9af in si_safe_eval (narg=2, V1=0x102ca64d1, V2=0x1) at /Users/raffaelc/Developer/lisp/ecl/build/clos/top.c:3888
#23 0x0000000100000e39 in main ()

warmest regards,

Ralph





Raffael Cavallaro
raffaelcavallaro at me.com