bug#26961: 26.0.50; Possible timming issue in regex-tests.el

bug#26961: 26.0.50; Possible timming issue in regex-tests.el

[Tino Calancha]

;; All tests performed from (expand-file-name "test" source-directory)

;;; I) Following fails:
emacs --batch -L ":." -l ert -l src/regex-tests.el \
--eval '(ert-run-tests-batch-and-exit nil)'

;;; II) This one fails in Debian-9, but it works in Fedora-25:
emacs --batch -L ":." -l ert -l src/regex-tests.el \
--eval '(let (arg) (ert-run-tests-batch-and-exit arg))'

;;; III) Following two commands works in both, Debian and Fedora:

emacs --batch -L ":." -l ert -l src/regex-tests.el \
-f ert-run-tests-batch-and-exit

emacs --batch -L ":." -l ert -l src/regex-tests.el \
--eval '(let (arg) (sleep-for 1) (ert-run-tests-batch-and-exit arg))'


In GNU Emacs 26.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
 of 2017-05-17 built on calancha-pc
Repository revision: f7c07930b581b1bcfdfb1874b6883233516bdf11
Windowing system distributor 'The X.Org Foundation', version 11.0.11902000
System Description:	Debian GNU/Linux 9.0 (stretch)

bug#26961: 26.0.50; Possible timming issue in regex-tests.el

[Tino Calancha]

Tino Calancha <tino.calancha@gmail.com> writes:

> ;;; II) This one fails in Debian-9, but it works in Fedora-25:
> emacs --batch -L ":." -l ert -l src/regex-tests.el \
> --eval '(let (arg) (ert-run-tests-batch-and-exit arg))'

> In GNU Emacs 26.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
> Repository revision: f7c07930b581b1bcfdfb1874b6883233516bdf11
> Windowing system distributor 'The X.Org Foundation', version 11.0.11902000
> System Description:	Debian GNU/Linux 9.0 (stretch)
I can reproduce the issue after compile Emacs without optimizations.
Following is the backtrace after Emacs crash:

(gdb) run -batch -L ":../test" -l ert -l ../test/src/regex-tests.el -eval '(let (arg) (ert-run-tests-batch-and-exit arg))'

Starting program: /home/calancha/soft/emacs-master/src/bootstrap-emacs -batch -L ":../test" -l ert -l ../test/src/regex-tests.el -eval '(let (arg) (ert-run-tests-batch-and-exit arg))'

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe5754700 (LWP 4349)]

Thread 1 "bootstrap-emacs" hit Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:363
363	  signal (sig, SIG_DFL);
(gdb) bt
#0  terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:363
#1  0x00000000005c1191 in emacs_abort () at sysdep.c:2371
#2  0x0000000000629189 in mark_object (arg=XIL(0x7fffffffbc54)) at alloc.c:6428
#3  0x00000000006299ae in mark_object (arg=XIL(0x2f44ac3)) at alloc.c:6667
#4  0x0000000000625a6c in mark_maybe_object (obj=XIL(0x2f44ac3)) at alloc.c:4788
#5  0x0000000000625e47 in mark_memory (start=0x7fffffff6b70, end=0x7fffffffe08f) at alloc.c:4940
#6  0x0000000000625e7c in mark_stack (bottom=0x7fffffffe08f "", end=0x7fffffff6b70 "\200\214!\001") at alloc.c:5138
#7  0x00000000006e01dc in mark_one_thread (thread=0xe1b2a0 <main_thread>) at thread.c:603
#8  0x00000000006e0371 in mark_threads_callback (ignore=0x0) at thread.c:634
#9  0x0000000000625ec4 in flush_stack_call_func (func=0x6e02de <mark_threads_callback>, arg=0x0) at alloc.c:5165
#10 0x00000000006e03a3 in mark_threads () at thread.c:641
#11 0x0000000000627e8b in garbage_collect_1 (end=0x7fffffff6d50) at alloc.c:5942
#12 0x0000000000628562 in Fgarbage_collect () at alloc.c:6108
#13 0x00000000005905a5 in maybe_gc () at lisp.h:4711
#14 0x000000000065085f in Ffuncall (nargs=2, args=0x7fffffff6e50) at eval.c:2726
#15 0x00000000006502f9 in call1 (fn=XIL(0xaa380), arg1=XIL(0x2fd0)) at eval.c:2606
#16 0x00000000005c9143 in Fkill_buffer (buffer_or_name=XIL(0x2f5ff35)) at buffer.c:1889
#17 0x000000000064f250 in eval_sub (form=XIL(0x2f278a3)) at eval.c:2220
#18 0x0000000000649ad3 in Fand (args=XIL(0x2f278b3)) at eval.c:384
#19 0x000000000064ee7c in eval_sub (form=XIL(0x2f278d3)) at eval.c:2173
#20 0x0000000000649e8b in Fprogn (body=XIL(0x2f278e3)) at eval.c:449
#21 0x0000000000649efc in prog_ignore (body=XIL(0x2f278e3)) at eval.c:461
#22 0x0000000000652ab5 in do_one_unbind (this_binding=0x7fffffff7260, unwinding=true, bindflag=SET_INTERNAL_UNBIND) at eval.c:3367
#23 0x0000000000652f18 in unbind_to (count=82, value=XIL(0x2ef8474)) at eval.c:3486
#24 0x000000000064c40c in Funwind_protect (args=XIL(0x2f2fb73)) at eval.c:1186
#25 0x000000000064ee7c in eval_sub (form=XIL(0x2f2fb63)) at eval.c:2173
#26 0x0000000000649e8b in Fprogn (body=XIL(0x2f2f413)) at eval.c:449
#27 0x000000000063a45e in Fsave_current_buffer (args=XIL(0x2f2f403)) at editfns.c:1061
#28 0x000000000064ee7c in eval_sub (form=XIL(0x2f2fbd3)) at eval.c:2173
#29 0x0000000000649e8b in Fprogn (body=XIL(0x2f2f423)) at eval.c:449
#30 0x000000000064bc42 in Flet (args=XIL(0x2f2f433)) at eval.c:963
#31 0x000000000064ee7c in eval_sub (form=XIL(0x2f2f443)) at eval.c:2173
#32 0x0000000000649e8b in Fprogn (body=XIL(0x2f2f483)) at eval.c:449
#33 0x0000000000651989 in funcall_lambda (fun=XIL(0x2f2f4e3), nargs=2, arg_vector=0x0) at eval.c:3015
#34 0x00000000006511ad in apply_lambda (fun=XIL(0x2f2f4f3), args=XIL(0x2f2ec23), count=75) at eval.c:2881
#35 0x000000000064f63c in eval_sub (form=XIL(0x2f2ec13)) at eval.c:2295
#36 0x000000000064b4f4 in FletX (args=XIL(0x2f2d7b3)) at eval.c:874
#37 0x000000000064ee7c in eval_sub (form=XIL(0x2f2d7c3)) at eval.c:2173
#38 0x0000000000649e8b in Fprogn (body=XIL(0x2f2d033)) at eval.c:449
#39 0x0000000000649cab in Fif (args=XIL(0x2f2d003)) at eval.c:407
#40 0x000000000064ee7c in eval_sub (form=XIL(0x2f2d7d3)) at eval.c:2173
#41 0x0000000000649e8b in Fprogn (body=XIL(0x2f2d053)) at eval.c:449
#42 0x000000000064ee7c in eval_sub (form=XIL(0x2f2d043)) at eval.c:2173
#43 0x0000000000649bf5 in Fif (args=XIL(0x2f2d073)) at eval.c:406
#44 0x000000000064ee7c in eval_sub (form=XIL(0x2f2d063)) at eval.c:2173
#45 0x0000000000649e8b in Fprogn (body=XIL(0x2f2d0c3)) at eval.c:449
#46 0x000000000064bc42 in Flet (args=XIL(0x2f2d143)) at eval.c:963
#47 0x000000000064ee7c in eval_sub (form=XIL(0x2f2d153)) at eval.c:2173
#48 0x0000000000649e8b in Fprogn (body=XIL(0x2f2d183)) at eval.c:449
#49 0x0000000000649efc in prog_ignore (body=XIL(0x2f2d183)) at eval.c:461
#50 0x000000000064bd22 in Fwhile (args=XIL(0x2f2d173)) at eval.c:982
#51 0x000000000064ee7c in eval_sub (form=XIL(0x2f2d163)) at eval.c:2173
#52 0x0000000000649e8b in Fprogn (body=XIL(0x2f2d1a3)) at eval.c:449
#53 0x000000000064bc42 in Flet (args=XIL(0x2f2d1b3)) at eval.c:963
#54 0x000000000064ee7c in eval_sub (form=XIL(0x2f2d1c3)) at eval.c:2173
#55 0x0000000000649e8b in Fprogn (body=XIL(0x2f2d203)) at eval.c:449
#56 0x000000000064ee7c in eval_sub (form=XIL(0x2f2d1d3)) at eval.c:2173
#57 0x000000000064c3f5 in Funwind_protect (args=XIL(0x2f2d223)) at eval.c:1185
#58 0x000000000064ee7c in eval_sub (form=XIL(0x2f2d213)) at eval.c:2173
#59 0x0000000000649e8b in Fprogn (body=XIL(0x2f2d2a3)) at eval.c:449
#60 0x000000000063a45e in Fsave_current_buffer (args=XIL(0x2f2d293)) at editfns.c:1061
#61 0x000000000064ee7c in eval_sub (form=XIL(0x2f2d283)) at eval.c:2173
#62 0x0000000000649e8b in Fprogn (body=XIL(0x2f2d2b3)) at eval.c:449
#63 0x000000000064bc42 in Flet (args=XIL(0x2f2d2c3)) at eval.c:963
#64 0x000000000064ee7c in eval_sub (form=XIL(0x2f2d2d3)) at eval.c:2173
#65 0x0000000000649e8b in Fprogn (body=XIL(0x2f2d2e3)) at eval.c:449
#66 0x000000000064bc42 in Flet (args=XIL(0x2f2d303)) at eval.c:963
#67 0x000000000064ee7c in eval_sub (form=XIL(0x2f2d313)) at eval.c:2173
#68 0x0000000000649e8b in Fprogn (body=XIL(0x2f2d343)) at eval.c:449
#69 0x0000000000651989 in funcall_lambda (fun=XIL(0x2f2d3a3), nargs=0, arg_vector=0x0) at eval.c:3015
#70 0x0000000000650a8c in Ffuncall (nargs=1, args=0x7fffffff8f00) at eval.c:2758
#71 0x000000000064f783 in Fapply (nargs=2, args=0x7fffffff8f00) at eval.c:2328
#72 0x000000000064f08e in eval_sub (form=XIL(0x2f36223)) at eval.c:2191
#73 0x000000000064a0e7 in Fsetq (args=XIL(0x2f36243)) at eval.c:511
#74 0x000000000064ee7c in eval_sub (form=XIL(0x2f36253)) at eval.c:2173
#75 0x000000000064c3f5 in Funwind_protect (args=XIL(0x2f35543)) at eval.c:1185
#76 0x000000000064ee7c in eval_sub (form=XIL(0x2f35533)) at eval.c:2173
#77 0x000000000064f17e in eval_sub (form=XIL(0x2f35583)) at eval.c:2208
#78 0x0000000000649b93 in Fif (args=XIL(0x2f355b3)) at eval.c:403
#79 0x000000000064ee7c in eval_sub (form=XIL(0x2f355a3)) at eval.c:2173
#80 0x0000000000649e8b in Fprogn (body=XIL(0x2f355f3)) at eval.c:449
#81 0x000000000064bc42 in Flet (args=XIL(0x2f35603)) at eval.c:963
#82 0x000000000064ee7c in eval_sub (form=XIL(0x2f35613)) at eval.c:2173
#83 0x0000000000649e8b in Fprogn (body=XIL(0x2f35623)) at eval.c:449
#84 0x000000000064bc42 in Flet (args=XIL(0x2f35643)) at eval.c:963
#85 0x000000000064ee7c in eval_sub (form=XIL(0x2f35653)) at eval.c:2173
#86 0x0000000000649e8b in Fprogn (body=XIL(0x2f35663)) at eval.c:449
#87 0x000000000064bc42 in Flet (args=XIL(0x2f35673)) at eval.c:963
#88 0x000000000064ee7c in eval_sub (form=XIL(0x2f35683)) at eval.c:2173
#89 0x0000000000649e8b in Fprogn (body=XIL(0x2f356b3)) at eval.c:449
#90 0x0000000000651989 in funcall_lambda (fun=XIL(0x2f3c023), nargs=0, arg_vector=0x0) at eval.c:3015
#91 0x0000000000650a8c in Ffuncall (nargs=1, args=0x7fffffff9c90) at eval.c:2758
#92 0x00000000006a12f6 in exec_byte_code (bytestr=XIL(0x2e7b1d4), vector=XIL(0x1454ebd), maxdepth=XIL(0x26), args_template=XIL(0x406), nargs=1, args=0x7fffffffa238) at bytecode.c:641
#93 0x0000000000651573 in funcall_lambda (fun=XIL(0x1455c35), nargs=1, arg_vector=0x7fffffffa230) at eval.c:2944
#94 0x0000000000650986 in Ffuncall (nargs=2, args=0x7fffffffa228) at eval.c:2746
#95 0x00000000006a12f6 in exec_byte_code (bytestr=XIL(0x2e6e1e4), vector=XIL(0x1455d65), maxdepth=XIL(0x36), args_template=XIL(0x406), nargs=1, args=0x7fffffffa7b0) at bytecode.c:641
#96 0x0000000000651573 in funcall_lambda (fun=XIL(0x1455e8d), nargs=1, arg_vector=0x7fffffffa7a8) at eval.c:2944
#97 0x0000000000650986 in Ffuncall (nargs=2, args=0x7fffffffa7a0) at eval.c:2746
#98 0x00000000006a12f6 in exec_byte_code (bytestr=XIL(0x2e78384), vector=XIL(0x1488ee5), maxdepth=XIL(0x3a), args_template=XIL(0xc0e), nargs=3, args=0x7fffffffad48) at bytecode.c:641
#99 0x0000000000651573 in funcall_lambda (fun=XIL(0x1488fad), nargs=3, arg_vector=0x7fffffffad30) at eval.c:2944
#100 0x0000000000650986 in Ffuncall (nargs=4, args=0x7fffffffad28) at eval.c:2746
#101 0x00000000006a12f6 in exec_byte_code (bytestr=XIL(0x2ee9294), vector=XIL(0x1489c85), maxdepth=XIL(0x3a), args_template=XIL(0xc0a), nargs=3, args=0x7fffffffb2a0) at bytecode.c:641
#102 0x0000000000651573 in funcall_lambda (fun=XIL(0x1489d7d), nargs=3, arg_vector=0x7fffffffb288) at eval.c:2944
#103 0x0000000000650986 in Ffuncall (nargs=4, args=0x7fffffffb280) at eval.c:2746
#104 0x00000000006a12f6 in exec_byte_code (bytestr=XIL(0x2eea3d4), vector=XIL(0x14a4f45), maxdepth=XIL(0x16), args_template=XIL(0x402), nargs=1, args=0x7fffffffb750) at bytecode.c:641
#105 0x0000000000651573 in funcall_lambda (fun=XIL(0x14a4f6d), nargs=1, arg_vector=0x7fffffffb748) at eval.c:2944
#106 0x0000000000650986 in Ffuncall (nargs=2, args=0x7fffffffb740) at eval.c:2746
#107 0x00000000006a12f6 in exec_byte_code (bytestr=XIL(0x2eeafe4), vector=XIL(0x14a3dad), maxdepth=XIL(0x16), args_template=XIL(0x402), nargs=1, args=0x7fffffffbba8) at bytecode.c:641
#108 0x0000000000651573 in funcall_lambda (fun=XIL(0x14a3de5), nargs=1, arg_vector=0x7fffffffbba0) at eval.c:2944
#109 0x00000000006511ad in apply_lambda (fun=XIL(0x14a3de5), args=XIL(0x2f44b63), count=14) at eval.c:2881
#110 0x000000000064f449 in eval_sub (form=XIL(0x2f44b53)) at eval.c:2265
#111 0x0000000000649e8b in Fprogn (body=XIL(0x2f44b73)) at eval.c:449
#112 0x000000000064bc42 in Flet (args=XIL(0x2f44b43)) at eval.c:963
#113 0x000000000064ee7c in eval_sub (form=XIL(0x2f44b23)) at eval.c:2173
#114 0x000000000064e854 in Feval (form=XIL(0x2f44b23), lexical=XIL(0)) at eval.c:2042
#115 0x0000000000650e24 in funcall_subr (subr=0xd80af8 <Seval>, numargs=1, args=0x7fffffffc118) at eval.c:2821
#116 0x0000000000650952 in Ffuncall (nargs=2, args=0x7fffffffc110) at eval.c:2744
#117 0x00000000006a12f6 in exec_byte_code (bytestr=XIL(0xb1bdf4), vector=XIL(0xb1be15), maxdepth=XIL(0x5e), args_template=XIL(0x406), nargs=1, args=0x7fffffffca78) at bytecode.c:641
#118 0x0000000000651573 in funcall_lambda (fun=XIL(0xb1bdc5), nargs=1, arg_vector=0x7fffffffca70) at eval.c:2944
#119 0x0000000000650986 in Ffuncall (nargs=2, args=0x7fffffffca68) at eval.c:2746
#120 0x00000000006a12f6 in exec_byte_code (bytestr=XIL(0xb16404), vector=XIL(0xb16425), maxdepth=XIL(0x56), args_template=XIL(0x2), nargs=0, args=0x7fffffffd688) at bytecode.c:641
#121 0x0000000000651573 in funcall_lambda (fun=XIL(0xb163d5), nargs=0, arg_vector=0x7fffffffd688) at eval.c:2944
#122 0x0000000000650986 in Ffuncall (nargs=1, args=0x7fffffffd680) at eval.c:2746
#123 0x00000000006a12f6 in exec_byte_code (bytestr=XIL(0xb15354), vector=XIL(0xb15375), maxdepth=XIL(0x32), args_template=XIL(0x2), nargs=0, args=0x7fffffffdcc0) at bytecode.c:641
#124 0x0000000000651573 in funcall_lambda (fun=XIL(0xb15325), nargs=0, arg_vector=0x7fffffffdcc0) at eval.c:2944
#125 0x00000000006511ad in apply_lambda (fun=XIL(0xb15325), args=XIL(0), count=4) at eval.c:2881
#126 0x000000000064f449 in eval_sub (form=XIL(0x14dde43)) at eval.c:2265
#127 0x000000000064e854 in Feval (form=XIL(0x14dde43), lexical=XIL(0)) at eval.c:2042
#128 0x0000000000598073 in top_level_2 () at keyboard.c:1121
#129 0x000000000064cbc2 in internal_condition_case (bfun=0x598050 <top_level_2>, handlers=XIL(0x4dd0), hfun=0x597a55 <cmd_error>) at eval.c:1326
#130 0x00000000005980b8 in top_level_1 (ignore=XIL(0)) at keyboard.c:1129
#131 0x000000000064c0d4 in internal_catch (tag=XIL(0xbca0), func=0x598075 <top_level_1>, arg=XIL(0)) at eval.c:1091
#132 0x0000000000597fa2 in command_loop () at keyboard.c:1090
#133 0x000000000059753f in recursive_edit_1 () at keyboard.c:697
#134 0x0000000000597734 in Frecursive_edit () at keyboard.c:768
#135 0x00000000005952ef in main (argc=10, argv=0x7fffffffe208) at emacs.c:1690

Lisp Backtrace:
"Automatic GC" (0x0)
"run-hooks" (0xffff6e58)
"kill-buffer" (0xffff6f90)
"and" (0xffff7130)
"unwind-protect" (0xffff7370)
"save-current-buffer" (0xffff74e0)
"let" (0xffff76e0)
"regex-tests-BOOST-frob-escapes" (0xffff7830)
"let*" (0xffff7ae0)
"if" (0xffff7c60)
"progn" (0xffff7da0)
"if" (0xffff7ef0)
"let" (0xffff80f0)
"while" (0xffff8290)
"let" (0xffff84a0)
"progn" (0xffff85e0)
"unwind-protect" (0xffff8720)
"save-current-buffer" (0xffff8890)
"let" (0xffff8a90)
"let" (0xffff8cb0)
"regex-tests-BOOST" (0xffff8f08)
"apply" (0xffff8f00)
"setq" (0xffff9120)
"unwind-protect" (0xffff9260)
"not" (0xffff9370)
"if" (0xffff94c0)
"let" (0xffff96c0)
"let" (0xffff98c0)
"let" (0xffff9ac0)
0x2f3c030 Lisp type 3
"ert--run-test-internal" (0xffffa230)
"ert-run-test" (0xffffa7a8)
"ert-run-or-rerun-test" (0xffffad30)
"ert-run-tests" (0xffffb288)
"ert-run-tests-batch" (0xffffb748)
"ert-run-tests-batch-and-exit" (0xffffbba0)
"let" (0xffffbed0)
"eval" (0xffffc118)
"command-line-1" (0xffffca70)
"command-line" (0xffffd688)
"normal-top-level" (0xffffdcc0)

bug#26961: 26.0.50; Possible timming issue in regex-tests.el

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Date: Wed, 17 May 2017 22:55:51 +0900
> 
> > ;;; II) This one fails in Debian-9, but it works in Fedora-25:
> > emacs --batch -L ":." -l ert -l src/regex-tests.el \
> > --eval '(let (arg) (ert-run-tests-batch-and-exit arg))'
> 
> > In GNU Emacs 26.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
> > Repository revision: f7c07930b581b1bcfdfb1874b6883233516bdf11
> > Windowing system distributor 'The X.Org Foundation', version 11.0.11902000
> > System Description:	Debian GNU/Linux 9.0 (stretch)
> I can reproduce the issue after compile Emacs without optimizations.
> Following is the backtrace after Emacs crash:
> 
> (gdb) run -batch -L ":../test" -l ert -l ../test/src/regex-tests.el -eval '(let (arg) (ert-run-tests-batch-and-exit arg))'
> 
> Starting program: /home/calancha/soft/emacs-master/src/bootstrap-emacs -batch -L ":../test" -l ert -l ../test/src/regex-tests.el -eval '(let (arg) (ert-run-tests-batch-and-exit arg))'

It doesn't crash for me (but one of the tests does fail).

> #0  terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:363
> #1  0x00000000005c1191 in emacs_abort () at sysdep.c:2371
> #2  0x0000000000629189 in mark_object (arg=XIL(0x7fffffffbc54)) at alloc.c:6428
> #3  0x00000000006299ae in mark_object (arg=XIL(0x2f44ac3)) at alloc.c:6667
> #4  0x0000000000625a6c in mark_maybe_object (obj=XIL(0x2f44ac3)) at alloc.c:4788
> #5  0x0000000000625e47 in mark_memory (start=0x7fffffff6b70, end=0x7fffffffe08f) at alloc.c:4940
> #6  0x0000000000625e7c in mark_stack (bottom=0x7fffffffe08f "", end=0x7fffffff6b70 "\200\214!\001") at alloc.c:5138
> #7  0x00000000006e01dc in mark_one_thread (thread=0xe1b2a0 <main_thread>) at thread.c:603
> #8  0x00000000006e0371 in mark_threads_callback (ignore=0x0) at thread.c:634
> #9  0x0000000000625ec4 in flush_stack_call_func (func=0x6e02de <mark_threads_callback>, arg=0x0) at alloc.c:5165
> #10 0x00000000006e03a3 in mark_threads () at thread.c:641
> #11 0x0000000000627e8b in garbage_collect_1 (end=0x7fffffff6d50) at alloc.c:5942
> #12 0x0000000000628562 in Fgarbage_collect () at alloc.c:6108

Are you up to the task of debugging GC?  See etc/DEBUG for some
advice.

Thanks.

bug#26961: 26.0.50; Possible timming issue in regex-tests.el

[Tino Calancha]

Eli Zaretskii <eliz@gnu.org> writes:


>> > ;;; II) This one fails in Debian-9, but it works in Fedora-25:
>> > emacs --batch -L ":." -l ert -l src/regex-tests.el \
>> > --eval '(let (arg) (ert-run-tests-batch-and-exit arg))'
>
>> #0  terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:363
>> #1  0x00000000005c1191 in emacs_abort () at sysdep.c:2371
>> #2  0x0000000000629189 in mark_object (arg=XIL(0x7fffffffbc54)) at alloc.c:6428
>> #3  0x00000000006299ae in mark_object (arg=XIL(0x2f44ac3)) at alloc.c:6667
>> #4  0x0000000000625a6c in mark_maybe_object (obj=XIL(0x2f44ac3)) at alloc.c:4788
>> #5  0x0000000000625e47 in mark_memory (start=0x7fffffff6b70, end=0x7fffffffe08f) at alloc.c:4940
>> #6  0x0000000000625e7c in mark_stack (bottom=0x7fffffffe08f "", end=0x7fffffff6b70 "\200\214!\001") at alloc.c:5138
>> #7  0x00000000006e01dc in mark_one_thread (thread=0xe1b2a0 <main_thread>) at thread.c:603
>> #8  0x00000000006e0371 in mark_threads_callback (ignore=0x0) at thread.c:634
>> #9  0x0000000000625ec4 in flush_stack_call_func (func=0x6e02de <mark_threads_callback>, arg=0x0) at alloc.c:5165
>> #10 0x00000000006e03a3 in mark_threads () at thread.c:641
>> #11 0x0000000000627e8b in garbage_collect_1 (end=0x7fffffff6d50) at alloc.c:5942
>> #12 0x0000000000628562 in Fgarbage_collect () at alloc.c:6108
>
> Are you up to the task of debugging GC?  See etc/DEBUG for some
> advice.

The problem arise from the recursive call in mark_object:
mark_object (ptr->car);

In my example recipe, such call not always satisfy the sanity
checks.

With the following patch, i cannot reproduce the issue anymore.

commit 5d0ac7e21e5dbb5128310a3a5017795321f71736
Author: Tino Calancha <tino.calancha@gmail.com>
Date:   Thu May 18 15:44:10 2017 +0900

    * src/alloc.c (mark_object): Use mark_maybe_object (Bug#26961).

diff --git a/src/alloc.c b/src/alloc.c
index faa14eebb3..8555e3f4e4 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -6664,7 +6664,7 @@ mark_object (Lisp_Object arg)
 	    cdr_count = 0;
 	    goto loop;
 	  }
-	mark_object (ptr->car);
+	mark_maybe_object (ptr->car);
 	obj = ptr->u.cdr;
 	cdr_count++;
 	if (cdr_count == mark_object_loop_halt)

bug#26961: 26.0.50; Possible timming issue in regex-tests.el

[Andreas Schwab]

On Mai 18 2017, Tino Calancha <tino.calancha@gmail.com> wrote:

> commit 5d0ac7e21e5dbb5128310a3a5017795321f71736
> Author: Tino Calancha <tino.calancha@gmail.com>
> Date:   Thu May 18 15:44:10 2017 +0900
>
>     * src/alloc.c (mark_object): Use mark_maybe_object (Bug#26961).
>
> diff --git a/src/alloc.c b/src/alloc.c
> index faa14eebb3..8555e3f4e4 100644
> --- a/src/alloc.c
> +++ b/src/alloc.c
> @@ -6664,7 +6664,7 @@ mark_object (Lisp_Object arg)
>  	    cdr_count = 0;
>  	    goto loop;
>  	  }
> -	mark_object (ptr->car);
> +	mark_maybe_object (ptr->car);

If car is not a valid object you have a bug somewhere else.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#26961: 26.0.50; Possible timming issue in regex-tests.el

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Cc: 26961@debbugs.gnu.org, tino.calancha@gmail.com
> Date: Thu, 18 May 2017 16:00:31 +0900
> 
> The problem arise from the recursive call in mark_object:
> mark_object (ptr->car);

The recursive call cannot be the problem, as GC in general and
mark_object in particular are by definition recursive.  The problem is
elsewhere, and to track it down you need to look at the object that
causes the problem.

bug#26961: 26.0.50; Possible timming issue in regex-tests.el

[Tino Calancha]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tino Calancha <tino.calancha@gmail.com>
>> Cc: 26961@debbugs.gnu.org, tino.calancha@gmail.com
>> Date: Thu, 18 May 2017 16:00:31 +0900
>> 
>> The problem arise from the recursive call in mark_object:
>> mark_object (ptr->car);
>
> The recursive call cannot be the problem, as GC in general and
> mark_object in particular are by definition recursive.  The problem is
> elsewhere, and to track it down you need to look at the object that
> causes the problem.

Following diff hunk from commit
'Improve unescaped character literal warnings'
(16004397f4)
seems the origin of the problem: those lists with
defsym's in their heads.

diff --git a/src/lread.c b/src/lread.c
--- a/src/lread.c
+++ b/src/lread.c
@@ -963,9 +963,11 @@ load_warn_unescaped_character_literals (Lisp_Object file)
   AUTO_STRING (format,
                "Loading `%s': unescaped character literals %s detected!");
   AUTO_STRING (separator, ", ");
+  AUTO_STRING (inner_format, "`?%c'");
   CALLN (Fmessage,
          format, file,
-         Fmapconcat (Qstring,
+         Fmapconcat (list3 (Qlambda, list1 (Qchar),
+                            list3 (Qformat, inner_format, Qchar)),
                      Fsort (Vlread_unescaped_character_literals, Qlss),
                      separator));
 }

Do you think this code is wrong?

bug#26961: 26.0.50; Possible timming issue in regex-tests.el

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Cc: Andreas Schwab <schwab@suse.de>, Eli Zaretskii <eliz@gnu.org>
> Date: Fri, 19 May 2017 12:31:10 +0900
> 
> Following diff hunk from commit
> 'Improve unescaped character literal warnings'
> (16004397f4)
> seems the origin of the problem: those lists with
> defsym's in their heads.
> 
> diff --git a/src/lread.c b/src/lread.c
> --- a/src/lread.c
> +++ b/src/lread.c
> @@ -963,9 +963,11 @@ load_warn_unescaped_character_literals (Lisp_Object file)
>    AUTO_STRING (format,
>                 "Loading `%s': unescaped character literals %s detected!");
>    AUTO_STRING (separator, ", ");
> +  AUTO_STRING (inner_format, "`?%c'");
>    CALLN (Fmessage,
>           format, file,
> -         Fmapconcat (Qstring,
> +         Fmapconcat (list3 (Qlambda, list1 (Qchar),
> +                            list3 (Qformat, inner_format, Qchar)),
>                       Fsort (Vlread_unescaped_character_literals, Qlss),
>                       separator));
>  }
> 
> Do you think this code is wrong?

This does indeed look dangerous: we are in effect consing Lisp data
structures from stack-based Lisp objects, and then process them in a
way that could leave some of them lying around when this function
returns, and its stack becomes invalid.

Can you present the evidence that caused you to suspect this
particular change?  Were the "unescaped character literals" warning
displayed during the session which crashed?

bug#26961: 26.0.50; Possible timming issue in regex-tests.el

[Tino Calancha]

Eli Zaretskii <eliz@gnu.org> writes:

>> +  AUTO_STRING (inner_format, "`?%c'");
>>    CALLN (Fmessage,
>>           format, file,
>> -         Fmapconcat (Qstring,
>> +         Fmapconcat (list3 (Qlambda, list1 (Qchar),
>> +                            list3 (Qformat, inner_format, Qchar)),
>>                       Fsort (Vlread_unescaped_character_literals, Qlss),
>>                       separator));
>>  }
>> 
>> Do you think this code is wrong?
>
> This does indeed look dangerous: we are in effect consing Lisp data
> structures from stack-based Lisp objects, and then process them in a
> way that could leave some of them lying around when this function
> returns, and its stack becomes invalid.
>
> Can you present the evidence that caused you to suspect this
> particular change?  Were the "unescaped character literals" warning
> displayed during the session which crashed?
Yes, such warning always appear in the crash session.
Loading ‘/home/calancha/soft/emacs-master/test/src/regex-tests.el’: unescaped character literals `?;' detected!
Running 22 tests (2017-05-19 20:24:31+0900)

If i print out the string, when the object is a cons with its car the string
to print, as follows:


--8<-----------------------------cut here---------------start------------->8---
diff --git a/src/alloc.c b/src/alloc.c
index faa14eebb3..20cfb3c88e 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -6664,7 +6664,32 @@ mark_object (Lisp_Object arg)
 	    cdr_count = 0;
 	    goto loop;
 	  }
-	mark_object (ptr->car);
+        po = XPNTR (ptr->car);
+        switch (XTYPE (ptr->car))
+          {
+          case Lisp_String:
+            {
+              if (!STRING_MARKED_P (XSTRING (ptr->car)) &&
+                  !PURE_P (po)                          &&
+                  mem_find (po) == MEM_NIL)
+                {
+                  fprintf (stderr, "[ERROR] mem_find (po) = MEM_NIL, cons %p car %s cdr %p\n",
+                           ptr, XSTRING (ptr->car)->data, XPNTR (ptr->u.cdr));
+                  return;
+                }
+              else
+                {
+                  fprintf (stderr, "[OK] cons %p car %s cdr %p\n",
+                           ptr, XSTRING (ptr->car)->data, XPNTR (ptr->u.cdr));
+                }
+              break;
+            }
+          default:
+            {
+              mark_object (ptr->car);
+            }
+          }
+        mark_object (ptr->car);
 	obj = ptr->u.cdr;
 	cdr_count++;
 	if (cdr_count == mark_object_loop_halt)

--8<-----------------------------cut here---------------end--------------->8---
Then, i see that right before the crash, the string printed out is the name
of the test file containinig the unescaped characters.

[OK] cons 0x2f0a8f0 car /home/calancha/soft/emacs-master/test/src/regex-resources/BOOST.tests cdr 0x2f0a8e0
[ERROR] mem_find (po) = MEM_NIL, cons 0x2f45150 car ‚ cdr 0x2f45140
[OK] cons 0x16d8720 car /home/calancha/soft/emacs-master/test/src/regex-resources/PCRE.tests cdr 0x16d8730
[ERROR] mem_find (po) = MEM_NIL, cons 0x2f45150 car ‚ cdr 0x2f45140
[OK] cons 0x3009910 car /home/calancha/soft/emacs-master/test/src/regex-resources/PTESTS cdr 0x3009900
[ERROR] mem_find (po) = MEM_NIL, cons 0x2f45150 car ‚ cdr 0x2f45140


With:
Fmapconcat (Qstring,
insted of:
Fmapconcat (list3 (Qlambda, list1 (Qchar),
                   list3 (Qformat, inner_format, Qchar)),

we still see the warning, as we should because the test file contains
those chars, but there is _no_ crash.

bug#26961: 26.0.50; Possible timming issue in regex-tests.el

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Cc: 26961@debbugs.gnu.org,  schwab@suse.de, tino.calancha@gmail.com
> Date: Fri, 19 May 2017 20:38:40 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> +  AUTO_STRING (inner_format, "`?%c'");
> >>    CALLN (Fmessage,
> >>           format, file,
> >> -         Fmapconcat (Qstring,
> >> +         Fmapconcat (list3 (Qlambda, list1 (Qchar),
> >> +                            list3 (Qformat, inner_format, Qchar)),
> >>                       Fsort (Vlread_unescaped_character_literals, Qlss),
> >>                       separator));
> >>  }
> >> 
> >> Do you think this code is wrong?
> >
> > This does indeed look dangerous: we are in effect consing Lisp data
> > structures from stack-based Lisp objects, and then process them in a
> > way that could leave some of them lying around when this function
> > returns, and its stack becomes invalid.
> >
> > Can you present the evidence that caused you to suspect this
> > particular change?  Were the "unescaped character literals" warning
> > displayed during the session which crashed?
> Yes, such warning always appear in the crash session.

Does the problem go away if you replace each AUTO_STRING in
load_warn_unescaped_character_literals with build_string?  IOW,
instead of this:

  AUTO_STRING (separator, ", ");

use this:

  Lisp_Object separator = build_string (", ");

and similarly for all the other strings used in the CALLN call in
load_warn_unescaped_character_literals.

bug#26961: 26.0.50; Possible timming issue in regex-tests.el

[Tino Calancha]

On Sat, 20 May 2017, Eli Zaretskii wrote:

> Does the problem go away if you replace each AUTO_STRING in
> load_warn_unescaped_character_literals with build_string?  IOW,
> instead of this:
>
>  AUTO_STRING (separator, ", ");
>
> use this:
>
>  Lisp_Object separator = build_string (", ");
>
> and similarly for all the other strings used in the CALLN call in
> load_warn_unescaped_character_literals.
Yes, that change fixes the problem.  No crashes anymore.

bug#26961: 26.0.50; Possible timming issue in regex-tests.el

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Date: Sat, 20 May 2017 20:20:39 +0900 (JST)
> cc: Tino Calancha <tino.calancha@gmail.com>, 26961@debbugs.gnu.org, 
>     schwab@suse.de
> 
> On Sat, 20 May 2017, Eli Zaretskii wrote:
> 
> > Does the problem go away if you replace each AUTO_STRING in
> > load_warn_unescaped_character_literals with build_string?  IOW,
> > instead of this:
> >
> >  AUTO_STRING (separator, ", ");
> >
> > use this:
> >
> >  Lisp_Object separator = build_string (", ");
> >
> > and similarly for all the other strings used in the CALLN call in
> > load_warn_unescaped_character_literals.
> Yes, that change fixes the problem.  No crashes anymore.

Thanks, I installed such a change.