guile threading deadlock

["Linas Vepstas" <linasvepstas@gmail.com>]

I've got a little deadlock problem w/ guile.  Here's the pseudocode:

for (i=0; i<10 i++)  {
   pthread_create (load_scm, expr[i]);
}

void load_scm (char * expr) {
   scm_init_guile();
   scm_c_eval(expr);
   /* and pthread exit now that we're done */
}

The expr's are entirely scm lambda defines of one sort or another,
and do not do any actual computation.

The above deadlocks; (using guile-1.8.5) .

In the stack traces below,
Only three threads are deadlocked, in total.
The first is stuck in some sort of scheme thread exit code, the
second is stuck in gc, and the third is stuck in scm_init.

This is one of the cleanest set of stack traces I've seen; other
ones have one or two threads stuck in gc, many in scm_init.

I'm guessing there's some bug in the thread-exit code. I'm
thinking the guile thread-exit handler leaves some kind of
lock behind.

#0  0xffffe425 in __kernel_vsyscall ()
#1  0xf7e43589 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xf7e3eba6 in _L_lock_95 () from /lib/tls/i686/cmov/libpthread.so.0
#3  0xf7e3e58a in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0
#4  0xf782729c in scm_pthread_mutex_lock (mutex=0xf785c568) at threads.c:1444
#5  0xf7828ad5 in do_thread_exit (v=0x9179e18) at threads.c:483
#6  0xf77b4842 in c_body (d=0xf6657328) at continuations.c:350
#7  0xf7829b19 in scm_c_catch (tag=0x104, body=0xf77b4830 <c_body>,
    body_data=0xf6657328, handler=0xf77b4850 <c_handler>,
    handler_data=0xf6657328,
    pre_unwind_handler=0xf78293e0 <scm_handle_by_message_noexit>,
    pre_unwind_handler_data=0x0) at throw.c:200
#8  0xf77b4cf2 in scm_i_with_continuation_barrier (body=0xf77b4830 <c_body>,
    body_data=0xf6657328, handler=0xf77b4850 <c_handler>,
    handler_data=0xf6657328,
    pre_unwind_handler=0xf78293e0 <scm_handle_by_message_noexit>,
    pre_unwind_handler_data=0x0) at continuations.c:326
#9  0xf77b4dd3 in scm_c_with_continuation_barrier (
    func=0xf7828ab0 <do_thread_exit>, data=0x9179e18) at continuations.c:368
#10 0xf78288f9 in scm_i_with_guile_and_parent (
    func=0xf7828ab0 <do_thread_exit>, data=0x9179e18, parent=0xf7693e70)
    at threads.c:695
#11 0xf78289ee in scm_with_guile (func=0xf7828ab0 <do_thread_exit>,
    data=0x9179e18) at threads.c:683
#12 0xf7828a43 in on_thread_exit (v=0x9179e18) at threads.c:505
#13 0xf7e3bbb0 in __nptl_deallocate_tsd ()
   from /lib/tls/i686/cmov/libpthread.so.0
#14 0xf7e3c509 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#15 0xf7c3ae5e in clone () from /lib/tls/i686/cmov/libc.so.6

Not sure who called clone ... not my code ... this is confusing. ...

#0  0xffffe425 in __kernel_vsyscall ()
#1  0xf7e43589 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xf7e3eba6 in _L_lock_95 () from /lib/tls/i686/cmov/libpthread.so.0
#3  0xf7e3e58a in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0
#4  0xf782720b in scm_i_thread_put_to_sleep () at threads.c:1588
#5  0xf77d1c09 in scm_i_gc (what=0xf784702e "cells") at gc.c:552
#6  0xf77d1f4d in scm_gc_for_newcell (freelist=0xf785c7ac,
    free_cells=0xf5500664) at gc.c:509
#7  0xf77e6114 in scm_list_2 (e1=0xf769fab0, e2=0x911b230)
    at ../libguile/inline.h:115
#8  0xf77cb518 in ceval (x=0x404, env=0xf768e7f0) at eval.c:4459
#9  0xf77cb856 in ceval (x=0xf7687ac0, env=0xf768e7f0) at eval.c:3399
#10 0xf77cb856 in ceval (x=0xf768ea20, env=0xf768eb08) at eval.c:3399
#11 0xf77cbb93 in ceval (x=0xf76d93d0, env=0xf768ce68) at eval.c:3665
#12 0xf77cb856 in ceval (x=0xf76dac68, env=0xf768ce50) at eval.c:3399
#13 0xf77cc169 in ceval (x=0xf76d89d8, env=0xf768c8d8) at eval.c:3650
#14 0xf77cbb93 in ceval (x=0xf7673ca8, env=0xf768d638) at eval.c:3665
#15 0xf77cd2e6 in call_closure_1 (proc=0xf768d620, arg1=0xf768d5a0)
    at eval.c:5263
#16 0xf77cdedd in scm_map (proc=0xf768d620, arg1=0xf768d5b0, args=0x404)
    at eval.c:5491
#17 0xf77cb5ba in ceval (x=0x404, env=0xf768d5c8) at eval.c:4369
#18 0xf77cc169 in ceval (x=0xf768d5f8, env=0xf768d5c8) at eval.c:3650
#19 0xf77cc179 in ceval (x=0xf768d468, env=0xf768d0a8) at eval.c:3370
#20 0xf77cd00a in scm_primitive_eval_x (exp=0xf768d070) at eval.c:5923
#21 0xf7823bb8 in inner_eval_string (data=0xf768d040) at strports.c:500
#22 0xf77cefde in scm_c_with_fluid (fluid=0x9119900, value=0xf769ae80,
    cproc=0xf7823b90 <inner_eval_string>, cdata=0xf768d040) at fluids.c:459
#23 0xf77e8335 in scm_c_call_with_current_module (module=0xf769ae80,
    func=0xf7823b90 <inner_eval_string>, data=0xf768d040) at modules.c:104
#24 0xf7823e21 in scm_eval_string_in_module (string=0xf769f860,
    module=0xf769ae80) at strports.c:527
#25 0xf7823e55 in scm_eval_string (string=0xf769f860) at strports.c:535
#26 0xf7823e85 in scm_c_eval_string (
    expr=0xf5500d04 "(use-modules (ice-9 streams))\n") at strports.c:481
#27 0xf7829b19 in scm_c_catch (tag=0x104, body=0xf7823e60 <scm_c_eval_string>,
    body_data=0xf5500d04,
    handler=0xf79522f8
<opencog::SchemeEval::catch_handler_wrapper(void*, scm_unused_struct*,
scm_unused_struct*)>, handler_data=0x9115c38,
    pre_unwind_handler=0xf795236a
<opencog::SchemeEval::preunwind_handler_wrapper(void*,
scm_unused_struct*, scm_unused_struct*)>,
    pre_unwind_handler_data=0x9115c38) at throw.c:200
#28 0xf79525f2 in opencog::SchemeEval::eval (this=0x9115c38, expr=@0xf5e55ab0)
    at /home/linas/src/novamente/src/opencog-stage4/staging/opencog/guile/SchemeEval.cc:320

The stack continues into my code, a la pseudocode at top.

#0  0xffffe425 in __kernel_vsyscall ()
#1  0xf7e43589 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xf7e3eba6 in _L_lock_95 () from /lib/tls/i686/cmov/libpthread.so.0
#3  0xf7e3e58a in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0
#4  0xf7826fd7 in guilify_self_1 (base=<value optimized out>) at threads.c:448
#5  0xf78288ab in scm_i_init_thread_for_guile (base=0xf4308000,
    parent=0xf7693e70) at threads.c:570
#6  0xf7828b82 in scm_init_guile () at threads.c:674

stack continues in my code, a la pseudocode at top


--linas