Sat 12 Feb 2011 02:16:29 PM UTC, original submission:
Cedric Cellier posted an interesting bug report back in September:
http://thread.gmane.org/gmane.lisp.guile.user/8169
It was about 1.8, but the bugs are different in 1.9. Specifically, the program as it is segfaults directly, here with libgc from CVS:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff76d3710 (LWP 2983)]
0x00007ffff7a016e3 in GC_is_black_listed (h=0x633000, len=<value optimized out>) at blacklst.c:233
233 if (get_pht_entry_from_index(GC_old_normal_bl, index)
(gdb) thr apply all bt
Thread 2 (Thread 0x7ffff76d3710 (LWP 2983)):
#0 0x00007ffff7a016e3 in GC_is_black_listed (h=0x633000, len=<value optimized out>) at blacklst.c:233
#1 0x00007ffff79ff3db in GC_allochblk_nth (sz=512, kind=1, flags=0, n=14, may_split=<value optimized out>)
at allchblk.c:694
#2 0x00007ffff79ff7dc in GC_allochblk (sz=512, kind=1, flags=0) at allchblk.c:629
#3 0x00007ffff7a0c2fb in GC_new_hblk (gran=32, kind=1) at new_hblk.c:191
#4 0x00007ffff7a01593 in GC_allocobj (gran=32, kind=1) at alloc.c:1312
#5 0x00007ffff7a0658a in GC_generic_malloc_inner (lb=488, k=1) at malloc.c:126
#6 0x00007ffff7a06638 in GC_generic_malloc (lb=488, k=1) at malloc.c:166
#7 0x00007ffff7a06924 in GC_core_malloc (lb=488) at malloc.c:289
#8 0x00007ffff7d48c0a in guilify_self_1 (base=0x7ffff76d2da8) at threads.c:379
#9 0x00007ffff7cf762c in scm_i_init_guile (base=<value optimized out>) at init.c:408
#10 0x00007ffff7d4a6f8 in scm_i_init_thread_for_guile (base=0x7ffff76d2da8, parent=0x0) at threads.c:649
#11 0x00007ffff7d4a9a6 in scm_i_with_guile_and_parent (func=0x400704 <thread_with_guile>, data=0x0,
parent=<value optimized out>) at threads.c:786
#12 0x000000000040072e in the_thread ()
#13 0x00007ffff7a103c5 in GC_inner_start_routine (sb=<value optimized out>, arg=<value optimized out>) at pthread_start.c:59
#14 0x00007ffff7a0a525 in GC_call_with_stack_base (fn=<value optimized out>, arg=<value optimized out>) at misc.c:1491
#15 0x0000003cc8c07761 in start_thread (arg=0x7ffff76d3710) at pthread_create.c:301
#16 0x0000003cc84e14fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
Thread 1 (Thread 0x7ffff76d5700 (LWP 2980)):
#0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
#1 0x0000003cc8c092c5 in _L_lock_868 () from /lib64/libpthread.so.0
#2 0x0000003cc8c09197 in __pthread_mutex_lock (mutex=0x7ffff7c2b740) at pthread_mutex_lock.c:61
#3 0x00007ffff7a11629 in GC_pthread_create (new_thread=0x7fffffffe058, attr=0x0, start_routine=0x400713 <the_thread>,
arg=0x0) at pthread_support.c:1508
#4 0x0000000000400758 in main ()
But if you do a scm_init_guile in the main thread first, instead we get, eventually:
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff741c710 (LWP 2845)]
0x0000003cc84329a5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0 0x0000003cc84329a5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x0000003cc8434185 in abort () at abort.c:92
#2 0x00007ffff7d48d5d in guilify_self_1 (base=0x7ffff741bda8) at threads.c:422
#3 0x00007ffff7d4a6de in scm_i_init_thread_for_guile (base=0x7ffff741bda8, parent=0x92e730) at threads.c:658
#4 0x00007ffff7d4a9a6 in scm_i_with_guile_and_parent (func=0x400754 <thread_with_guile>, data=0x0,
parent=<value optimized out>) at threads.c:786
#5 0x000000000040077e in the_thread ()
#6 0x00007ffff7a103c5 in GC_inner_start_routine (sb=<value optimized out>, arg=<value optimized out>) at pthread_start.c:59
#7 0x00007ffff7a0a525 in GC_call_with_stack_base (fn=<value optimized out>, arg=<value optimized out>) at misc.c:1491
#8 0x0000003cc8c07761 in start_thread (arg=0x7ffff741c710) at pthread_create.c:301
#9 0x0000003cc84e14fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
(gdb) fr 2
#2 0x00007ffff7d48d5d in guilify_self_1 (base=0x7ffff741bda8) at threads.c:422
422 abort ();
(gdb) l
417
418 if (pipe (t->sleep_pipe) != 0)
419 /* FIXME: Error conditions during the initialization phase are handled
420 gracelessly since public functions such as `scm_init_guile ()'
421 currently have type `void'. */
422 abort ();
423
424 scm_i_pthread_mutex_init (&t->admin_mutex, NULL);
425 t->current_mark_stack_ptr = NULL;
426 t->current_mark_stack_limit = NULL;
It seems that the sleep pipe is never being closed, which would seem to indicate that the threads's cleanup function is not being called.
|