[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the state of the concurrency branch
From: |
Eli Zaretskii |
Subject: |
Re: the state of the concurrency branch |
Date: |
Sun, 01 Sep 2013 18:49:19 +0300 |
> Date: Sat, 31 Aug 2013 16:42:46 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
>
> 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.
- Re: the state of the concurrency branch,
Eli Zaretskii <=