From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Linas Vepstas" Newsgroups: gmane.lisp.guile.user Subject: guile threading deadlock Date: Fri, 7 Nov 2008 20:26:04 -0600 Message-ID: <3ae3aa420811071826q7e4a153at16a67efbe7261b6d@mail.gmail.com> Reply-To: linasvepstas@gmail.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1226111181 30452 80.91.229.12 (8 Nov 2008 02:26:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Nov 2008 02:26:21 +0000 (UTC) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Nov 08 03:27:24 2008 connect(): Connection refused Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KydXn-0007ht-63 for guile-user@m.gmane.org; Sat, 08 Nov 2008 03:27:23 +0100 Original-Received: from localhost ([127.0.0.1]:43349 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KydWf-0005MT-N8 for guile-user@m.gmane.org; Fri, 07 Nov 2008 21:26:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KydWa-0005MI-IX for guile-user@gnu.org; Fri, 07 Nov 2008 21:26:08 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KydWZ-0005L4-2t for guile-user@gnu.org; Fri, 07 Nov 2008 21:26:07 -0500 Original-Received: from [199.232.76.173] (port=46603 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KydWY-0005L1-UK for guile-user@gnu.org; Fri, 07 Nov 2008 21:26:06 -0500 Original-Received: from fg-out-1718.google.com ([72.14.220.152]:44238) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KydWY-0002oY-Dr for guile-user@gnu.org; Fri, 07 Nov 2008 21:26:06 -0500 Original-Received: by fg-out-1718.google.com with SMTP id l26so1358663fgb.30 for ; Fri, 07 Nov 2008 18:26:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=V4TrB1B8nehfNU4c6EaiJWwbffIg9wTD3M4Ui7PbEwk=; b=jORpW/0+EVIqakBjpuvIhOqDfAbNewZnwztYACNZ+pXVVgekkCsk33HuNZLH+Kle2A sRkbhJnhU6/uWqpNsbttxbjMXoMKL3LON7qK8zNvJgMbgjrwzWGvQCEhTe2bHm87JrBp YKcffINM2XJRxKr+7WESb83QxbmYnLGkymjoo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=UkltlvxWoOUcK+M9H9mjQ5wvCt1NUGqfDJOyl1gWRrLRhcpgNwFw3wPKeTYkdPnqjU J1dCYeSfiajxsT96wTy3DXAAmD8VQgwEOJdyToweh0haP2KWQM9sArs4zyjBNQoHS+bB xEtepNHpwxzJJ2wCqWgvqH/t1KlTnr0imOS48= Original-Received: by 10.187.163.5 with SMTP id q5mr872603fao.8.1226111164920; Fri, 07 Nov 2008 18:26:04 -0800 (PST) Original-Received: by 10.187.180.8 with HTTP; Fri, 7 Nov 2008 18:26:04 -0800 (PST) Content-Disposition: inline X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:6854 Archived-At: 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 , body_data=0xf6657328, handler=0xf77b4850 , handler_data=0xf6657328, pre_unwind_handler=0xf78293e0 , pre_unwind_handler_data=0x0) at throw.c:200 #8 0xf77b4cf2 in scm_i_with_continuation_barrier (body=0xf77b4830 , body_data=0xf6657328, handler=0xf77b4850 , handler_data=0xf6657328, pre_unwind_handler=0xf78293e0 , pre_unwind_handler_data=0x0) at continuations.c:326 #9 0xf77b4dd3 in scm_c_with_continuation_barrier ( func=0xf7828ab0 , data=0x9179e18) at continuations.c:368 #10 0xf78288f9 in scm_i_with_guile_and_parent ( func=0xf7828ab0 , data=0x9179e18, parent=0xf7693e70) at threads.c:695 #11 0xf78289ee in scm_with_guile (func=0xf7828ab0 , 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 , cdata=0xf768d040) at fluids.c:459 #23 0xf77e8335 in scm_c_call_with_current_module (module=0xf769ae80, func=0xf7823b90 , 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 , body_data=0xf5500d04, handler=0xf79522f8 , handler_data=0x9115c38, pre_unwind_handler=0xf795236a , 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=) 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