From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: the state of the concurrency branch Date: Sun, 01 Sep 2013 18:49:19 +0300 Message-ID: <838uzgee4g.fsf@gnu.org> References: <87vc2t7erx.fsf@fleche.redhat.com> <83txicffpe.fsf@gnu.org> <87haeb3lwp.fsf@fleche.redhat.com> <83mwo3f762.fsf@gnu.org> <831u5dg4xz.fsf@gnu.org> <874na9talu.fsf@fleche.redhat.com> <83y57kedo5.fsf@gnu.org> <83hae6dvxz.fsf@gnu.org> <83eh9adqnw.fsf@gnu.org> <83d2oudlih.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1378050567 1495 80.91.229.3 (1 Sep 2013 15:49:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Sep 2013 15:49:27 +0000 (UTC) Cc: lekktu@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: tromey@redhat.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 01 17:49:28 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VG9u2-0001yl-Ix for ged-emacs-devel@m.gmane.org; Sun, 01 Sep 2013 17:49:26 +0200 Original-Received: from localhost ([::1]:34383 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VG9u2-0005Al-2D for ged-emacs-devel@m.gmane.org; Sun, 01 Sep 2013 11:49:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VG9tu-00059m-Bg for emacs-devel@gnu.org; Sun, 01 Sep 2013 11:49:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VG9to-0006kh-VY for emacs-devel@gnu.org; Sun, 01 Sep 2013 11:49:18 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:42600) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VG9to-0006jV-Hu for emacs-devel@gnu.org; Sun, 01 Sep 2013 11:49:12 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MSG00I00EHMNM00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Sun, 01 Sep 2013 18:49:11 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MSG00I6IELXIRA0@a-mtaout23.012.net.il>; Sun, 01 Sep 2013 18:49:10 +0300 (IDT) In-reply-to: <83d2oudlih.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:163119 Archived-At: > Date: Sat, 31 Aug 2013 16:42:46 +0300 > From: Eli Zaretskii > Cc: lekktu@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org > > Breakpoint 3, 0x77c36d74 in msvcrt!longjmp () > from C:\WINDOWS\system32\msvcrt.dll > #0 0x77c36d74 in msvcrt!longjmp () from C:\WINDOWS\system32\msvcrt.dll > #1 0x01174a1e in unwind_to_catch (catch=0x4e7feb8, value=60183150) > at eval.c:1188 > #2 0x011757e2 in Fsignal (error_symbol=55041314, data=60183142) > at eval.c:1607 > #3 0x01175869 in xsignal (error_symbol=55041314, data=60183142) > at eval.c:1628 > #4 0x011758cf in xsignal2 (error_symbol=55041314, arg1=55041794, > arg2=370042113) at eval.c:1649 > #5 0x01159a87 in wrong_type_argument (predicate=82312904, value=60157272) > at data.c:189 > #6 0x0115b7de in find_symbol_value (symbol=370042113) at data.c:1147 > #7 0x01179dab in unbind_for_thread_switch () at eval.c:3495 > #8 0x011eb163 in post_acquire_global_lock (self=0x1501cd0 ) > at thread.c:65 > #9 0x011eb252 in acquire_global_lock (self=0x1501cd0 ) > at thread.c:90 > gdb: unknown target exception 0xc0000027 at 0x77c35464 > > Program received signal ?, Unknown signal. > 0x77c35464 in msvcrt!_global_unwind2 () from C:\WINDOWS\system32\msvcrt.dll > > It seems like the primary thread is signaling a wrong-type-argument > error, when it tries to unbind thread-local variables before switching > to a different thread. Did Fsignal try to use a wrong 'struct > handler', one that belongs to a different thread? Answering my own question: yes, Fsignal tried to throw to a handler that belonged to a different thread. This is because unbind_for_thread_switch is called in the context of a new thread, but current_thread is still set to the old one. I think I fixed this in revision 109719 on the concurrency branch. > Setting a breakpoint in wrong_type_argument, I see this: > > Breakpoint 3, wrong_type_argument (predicate=55041794, value=8580880) > at data.c:189 > 189 xsignal2 (Qwrong_type_argument, predicate, value); > (gdb) bt > #0 wrong_type_argument (predicate=55041794, value=8580880) at data.c:189 > #1 0x0115b7de in find_symbol_value (symbol=8580880) at data.c:1147 > #2 0x01179dab in unbind_for_thread_switch () at eval.c:3495 > #3 0x011eb163 in post_acquire_global_lock (self=0x1501cd0 ) > at thread.c:65 > #4 0x011eb252 in acquire_global_lock (self=0x1501cd0 ) > at thread.c:90 > #5 0x011ebd53 in yield_callback (ignore=0x0) at thread.c:601 > #6 0x01155e4d in flush_stack_call_func (func=0x11ebd30 , > arg=0x0) at alloc.c:4777 > #7 0x011ebd6f in Fthread_yield () at thread.c:608 > #8 0x011770ac in eval_sub (form=56246638) at eval.c:2240 > #9 0x01172da3 in Fprogn (body=56246646) at eval.c:480 > #10 0x01174591 in Fwhile (args=56246630) at eval.c:1010 > #11 0x01176db9 in eval_sub (form=56246606) at eval.c:2191 > #12 0x01172da3 in Fprogn (body=56246654) at eval.c:480 > #13 0x01176db9 in eval_sub (form=56246526) at eval.c:2191 > #14 0x011768d3 in Feval (form=56246526, lexical=54986778) at eval.c:2062 > #15 0x011784b1 in Ffuncall (nargs=3, args=0x82f448) at eval.c:2876 > #16 0x011bd36c in exec_byte_code (bytestr=20123049, vector=20123069, > maxdepth=16, args_template=54986778, nargs=0, args=0x0) at bytecode.c:902 > #17 0x01179016 in funcall_lambda (fun=20123021, nargs=1, arg_vector=0x82f618) > at eval.c:3107 > #18 0x011786c3 in Ffuncall (nargs=2, args=0x82f614) at eval.c:2922 > #19 0x011bd36c in exec_byte_code (bytestr=20123489, vector=20123509, > maxdepth=12, args_template=54986778, nargs=0, args=0x0) at bytecode.c:902 > #20 0x01179016 in funcall_lambda (fun=20123461, nargs=1, arg_vector=0x82f824) > at eval.c:3107 > #21 0x011786c3 in Ffuncall (nargs=2, args=0x82f820) at eval.c:2922 > #22 0x01171e00 in Fcall_interactively (function=56891970, > record_flag=54986778, keys=55033861) at callint.c:836 > #23 0x011784e7 in Ffuncall (nargs=4, args=0x82fa0c) at eval.c:2880 > #24 0x011bd36c in exec_byte_code (bytestr=19816129, vector=19816149, > maxdepth=52, args_template=4100, nargs=1, args=0x82fbf0) at bytecode.c:902 > #25 0x01178c6b in funcall_lambda (fun=19816109, nargs=1, arg_vector=0x82fbec) > at eval.c:3041 > #26 0x011786c3 in Ffuncall (nargs=2, args=0x82fbe8) at eval.c:2922 > #27 0x01177f76 in call1 (fn=55032674, arg1=56891970) at eval.c:2672 > #28 0x010e2f06 in command_loop_1 () at keyboard.c:1560 > #29 0x011750c4 in internal_condition_case (bfun=0x10e26a5 , > handlers=55041242, hfun=0x10e1f31 ) at eval.c:1359 > #30 0x010e2374 in command_loop_2 (ignore=54986778) at keyboard.c:1161 > #31 0x01174938 in internal_catch (tag=55031122, > func=0x10e2351 , arg=54986778) at eval.c:1133 > #32 0x010e232c in command_loop () at keyboard.c:1140 > #33 0x010e1ae3 in recursive_edit_1 () at keyboard.c:779 > #34 0x010e1c97 in Frecursive_edit () at keyboard.c:843 > #35 0x010dfee0 in main (argc=2, argv=0xa42880) at emacs.c:1564 > > Lisp Backtrace: > "thread-yield" (0x4e7fb08) > "let" (0x4e7fd58) > "threads-test-thread2" (0x3516f5c) > (gdb) up 2 > #2 0x01179dab in unbind_for_thread_switch () at eval.c:3495 > 3495 bind->let.saved_value = find_symbol_value (specpdl_symbol (bin > d)); > (gdb) p bind > $2 = (union specbinding *) 0x34dac64 > (gdb) p bind->let > $3 = { > kind = 72, <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > symbol = 8580880, > old_value = 54986778, > where = 1, > saved_value = -1 > } > > Isn't 72 a value that should never happen in bind->kind? Any idea how > this could happen? This part still happens sometimes, but at least now Emacs signals an error and doesn't crash.