Re: the state of the concurrency branch

[Eli Zaretskii]

> 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?