Re: the state of the concurrency branch

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 31 Aug 2013 16:42:46 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 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 <primary_thread>)
>       at thread.c:65
>   #9  0x011eb252 in acquire_global_lock (self=0x1501cd0 <primary_thread>)
>       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 <primary_thread>)
>       at thread.c:65
>   #4  0x011eb252 in acquire_global_lock (self=0x1501cd0 <primary_thread>)
>       at thread.c:90
>   #5  0x011ebd53 in yield_callback (ignore=0x0) at thread.c:601
>   #6  0x01155e4d in flush_stack_call_func (func=0x11ebd30 <yield_callback>,
>       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 <command_loop_1>,
>       handlers=55041242, hfun=0x10e1f31 <cmd_error>) 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 <command_loop_2>, 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.