Here's another one, I'm trying to dig into this: Its more or less the same crash as the one reported at:
http://bugs.gentoo.org/228097 and http://www.mail-archive.com/[EMAIL PROTECTED]/msg04568.html My stack below. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xf5333b90 (LWP 20587)] 0xf7711ce3 in scm_mark_locations (x=0xf5333110, n=4294966782) at gc-mark.c:435 435 SCM obj = * (SCM *) &x[m]; Current language: auto; currently c (gdb) bt #0 0xf7711ce3 in scm_mark_locations (x=0xf5333110, n=4294966782) at gc-mark.c:435 #1 0xf7766a12 in scm_threads_mark_stacks () at threads.c:1375 #2 0xf7711d38 in scm_mark_all () at gc-mark.c:82 #3 0xf7710d33 in scm_i_gc (what=0xf778602e "cells") at gc.c:598 #4 0xf7710f4d in scm_gc_for_newcell (freelist=0xf779b76c, free_cells=0x1228e9b0) at gc.c:509 #5 0xf7768bd8 in scm_c_catch (tag=0x104, body=0xf76f3830 <c_body>, body_data=0xf5333328, handler=0xf76f3850 <c_handler>, handler_data=0xf5333328, pre_unwind_handler=0xf77683e0 <scm_handle_by_message_noexit>, pre_unwind_handler_data=0x0) at ../libguile/inline.h:186 #6 0xf76f3cf2 in scm_i_with_continuation_barrier (body=0xf76f3830 <c_body>, body_data=0xf5333328, handler=0xf76f3850 <c_handler>, handler_data=0xf5333328, pre_unwind_handler=0xf77683e0 <scm_handle_by_message_noexit>, pre_unwind_handler_data=0x0) at continuations.c:326 #7 0xf76f3dd3 in scm_c_with_continuation_barrier ( func=0xf7767ab0 <do_thread_exit>, data=0x1228e938) at continuations.c:368 ---Type <return> to continue, or q <return> to quit--- #8 0xf77678f9 in scm_i_with_guile_and_parent (func=0xf7767ab0 <do_thread_exit>, data=0x1228e938, parent=0x19f63670) at threads.c:695 #9 0xf77679ee in scm_with_guile (func=0xf7767ab0 <do_thread_exit>, data=0x1228e938) at threads.c:683 #10 0xf7767a43 in on_thread_exit (v=0x1228e938) at threads.c:505 #11 0xf7d7abb0 in __nptl_deallocate_tsd () from /lib/tls/i686/cmov/libpthread.so.0 #12 0xf7d7b509 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #13 0xf7b79e5e in clone () from /lib/tls/i686/cmov/libc.so.6 (gdb) I've seen this twice now in two days, but its not readily reproducible. By plugging in the insanely large n into a hex calc, you'll see its actually 0xfffsomething. Looking carefully near threads.c:1375 seems to imply that stack top and stack bottom are reversed. So I added a printf at that location, and tried to reproduce the crash. Several gazzilion print statements later, no crash. I suspect that this is some sort of thread-race condition; I think it happens when I am defining some functions from several different threads at once. It seems *not* to occur once I get into hard-core computations-- i.e. it happens no later than the first few dozen gc's. This is on guile-1.8.5, --with-threads, on Ubuntu, Intel (actually AMD64 cpu.) --linas
