[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: |
Sat, 31 Aug 2013 16:42:46 +0300 |
> Date: Sat, 31 Aug 2013 14:51:31 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
>
> The resulting binary seems to pass the tests in
> test/automated/threads.el. There's some weird problem with the
> "simple test of threads and let bindings" test: it succeeds the first
> time, but if I run it twice, the second time crashes. The crash is
> not easy to interpret (the call stack is smashed), but it looks like
> some error inside the call to longjmp by the main thread, while the
> other thread is waiting for the global lock after it completed the
> thread-yield call. Any ideas?
More info: Here's the backtrace from the last call to longjmp that
seems to be triggering a fatal runtime exception:
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?
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?
- Re: the state of the concurrency branch, (continued)
- Re: the state of the concurrency branch, Tom Tromey, 2013/08/28
- Re: the state of the concurrency branch, Eli Zaretskii, 2013/08/28
- Re: the state of the concurrency branch, Stefan Monnier, 2013/08/28
- Re: the state of the concurrency branch, Tom Tromey, 2013/08/28
- Re: the state of the concurrency branch, Stefan Monnier, 2013/08/28
- Re: the state of the concurrency branch, Eli Zaretskii, 2013/08/28
- Re: the state of the concurrency branch, Tom Tromey, 2013/08/28
- Re: the state of the concurrency branch, Eli Zaretskii, 2013/08/29
- Re: the state of the concurrency branch, Eli Zaretskii, 2013/08/31
- Re: the state of the concurrency branch, Eli Zaretskii, 2013/08/31
- Re: the state of the concurrency branch,
Eli Zaretskii <=
- Re: the state of the concurrency branch, Stefan Monnier, 2013/08/27
- Re: the state of the concurrency branch, Tom Tromey, 2013/08/27
- Re: the state of the concurrency branch, Tom Tromey, 2013/08/27
- Re: the state of the concurrency branch, Eli Zaretskii, 2013/08/28