bug#24640: Crashes in 25.1

bug#24640: Crashes in 25.1

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 20263 bytes --]

Using 25.1 Ubuntu packages from https://launchpad.net/~adrozdoff

Core was generated by `/home/rrt/.local/bin/emacs'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007fe0d911f2a9 in raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/pt-raise.c:35
35 ../sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7fe0e00bab00 (LWP 16170))]
(gdb) where
#0  0x00007fe0d911f2a9 in raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/pt-raise.c:35
#1  0x00000000004ef104 in terminate_due_to_signal (sig=sig@entry=6,
backtrace_limit=backtrace_limit@entry=40) at emacs.c:381
#2  0x0000000000508383 in emacs_abort () at sysdep.c:2247
#3  0x0000000000563540 in Fsignal (error_symbol=error_symbol@entry=28656,
data=101381475) at eval.c:1478
#4  0x0000000000563549 in xsignal (error_symbol=error_symbol@entry=28656,
data=<optimised out>) at eval.c:1577
#5  0x0000000000563577 in xsignal1 (error_symbol=error_symbol@entry=28656,
arg=<optimised out>) at eval.c:1592
#6  0x00000000005330db in compile_pattern (posix=<optimised out>,
translate=0, pattern=<optimised out>, cp=0xb90db8 <searchbufs+1080>) at
search.c:154
#7  0x00000000005330db in compile_pattern (pattern=pattern@entry=52039844,
regp=regp@entry=0x0, translate=translate@entry=0, posix=posix@entry=false,
multibyte=<optimised out>) at search.c:237
#8  0x00000000005352a1 in fast_string_match_internal
(regexp=regexp@entry=52039844,
string=string@entry=91929188, table=table@entry=0) at search.c:471
#9  0x000000000051cf51 in Ffind_file_name_handler (string=91929188,
regexp=52039844) at lisp.h:4010
#10 0x000000000051cf51 in Ffind_file_name_handler
(filename=filename@entry=91929188,
operation=operation@entry=19872)
    at fileio.c:292
#11 0x000000000051e460 in Fexpand_file_name (name=91929188,
default_directory=default_directory@entry=0) at fileio.c:809
#12 0x000000000052425d in Fdo_auto_save (no_message=<optimised out>,
    no_message@entry=44448, current_only=current_only@entry=0) at
fileio.c:5521
#13 0x00000000004eef20 in shut_down_emacs (sig=sig@entry=11,
stuff=stuff@entry=0) at emacs.c:2000
#14 0x00000000004ef0d5 in terminate_due_to_signal (sig=sig@entry=11,
backtrace_limit=backtrace_limit@entry=40) at emacs.c:365
#15 0x0000000000506fce in handle_fatal_signal (sig=sig@entry=11) at
sysdep.c:1601
#16 0x00000000005071f3 in deliver_thread_signal (sig=sig@entry=11,
handler=0x506fc0 <handle_fatal_signal>) at sysdep.c:1575
#17 0x000000000050725f in handle_sigsegv (sig=11) at sysdep.c:1613
#18 0x000000000050725f in handle_sigsegv (sig=11, siginfo=<optimised out>,
arg=<optimised out>) at sysdep.c:1695
#19 0x00007fe0d911f3d0 in <signal handler called> () at
/lib/x86_64-linux-gnu/libpthread.so.0
#20 0x000000000054a8e9 in mark_object (arg=<optimised out>) at alloc.c:6446
#21 0x000000000054a9cb in mark_object (arg=<optimised out>) at alloc.c:6539
#22 0x000000000054a9cb in mark_object (arg=<optimised out>) at alloc.c:6539
#23 0x000000000054b20c in Fgarbage_collect (end=0x7fff0376df88) at
alloc.c:5745
#24 0x000000000054b20c in Fgarbage_collect () at alloc.c:5979
#25 0x000000000059979e in exec_byte_code () at lisp.h:4656
#26 0x000000000059979e in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>,
args_template=args_template@entry=0, nargs=nargs@entry=0, args=<optimised
out>, args@entry=0x0) at bytecode.c:714
#27 0x000000000056283f in funcall_lambda (fun=78975333, nargs=nargs@entry=1,
arg_vector=arg_vector@entry=0x7fff0376e300)
    at eval.c:2921
#28 0x0000000000562c3b in Ffuncall (nargs=2, args=args@entry=0x7fff0376e2f8)
at eval.c:2754
#29 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>,
args_template=args_template@entry=0, nargs=nargs@entry=0, args=<optimised
out>, args@entry=0x0) at bytecode.c:880
#30 0x000000000056283f in funcall_lambda (fun=78974597, nargs=nargs@entry=2,
arg_vector=arg_vector@entry=0x7fff0376e520)
    at eval.c:2921
#31 0x0000000000562c3b in Ffuncall (nargs=3, args=args@entry=0x7fff0376e518)
at eval.c:2754
#32 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>,
args_template=args_template@entry=0, nargs=nargs@entry=0, args=<optimised
out>, args@entry=0x0) at bytecode.c:880
#33 0x000000000056283f in funcall_lambda (fun=78926773, nargs=nargs@entry=1,
arg_vector=arg_vector@entry=0x7fff0376e740)
    at eval.c:2921
#34 0x0000000000562c3b in Ffuncall (nargs=2, args=args@entry=0x7fff0376e738)
at eval.c:2754
#35 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>,
args_template=args_template@entry=0, nargs=nargs@entry=0, args=<optimised
out>, args@entry=0x0) at bytecode.c:880
#36 0x000000000056283f in funcall_lambda (fun=78925797, nargs=nargs@entry=2,
arg_vector=arg_vector@entry=0x7fff0376e958)
    at eval.c:2921
#37 0x0000000000562c3b in Ffuncall (nargs=nargs@entry=3,
args=0x7fff0376e950) at eval.c:2754
#38 0x0000000000564020 in Fapply (nargs=nargs@entry=2,
args=args@entry=0x7fff0376ea10)
at eval.c:2321
#39 0x000000000056425c in apply1 (fn=56303360, arg=<optimised out>) at
eval.c:2537
#40 0x000000000056163e in internal_condition_case_1 (bfun=bfun@entry=0x59b3f0
<read_process_output_call>, arg=103083523, handlers=handlers@entry=19056,
hfun=hfun@entry=0x59b370 <read_process_output_error_handler>) at eval.c:1333
#41 0x000000000059af2d in read_process_output (coding=0x53b3920,
nbytes=652, chars=0x7fff0376eaa0 "Unescaped left brace in regex is
deprecated, passed through in regex; marked by <-- HERE in m/\\\\begin{ <--
HERE tex}(.*?)\\\\end{tex}/ at /usr/bin/texify line 521.\nUnescaped left
brace in regex is depre"..., p=0x287) at process.c:5440
#42 0x000000000059af2d in read_process_output (proc=proc@entry=86121909,
channel=<optimised out>) at process.c:5351
#43 0x000000000059cd88 in status_notify
(deleting_process=deleting_process@entry=0x0, wait_proc=wait_proc@entry=0x0)
    at process.c:6655
#44 0x00000000005a37ae in wait_reading_process_output
(time_limit=<optimised out>, nsecs=<optimised out>, read_kbd=read_kbd@entry=-1,
do_display=do_display@entry=true, wait_for_cell=wait_for_cell@entry=0,
wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:4663
#45 0x00000000004fa0b4 in read_char (end_time=0x7fff037706f0,
used_mouse_menu=0x0, kbp=<synthetic pointer>)
    at keyboard.c:3798
#46 0x00000000004fa0b4 in read_char (used_mouse_menu=<optimised out>,
local_getcjmp=<optimised out>, end_time=<optimised out>) at keyboard.c:2148
#47 0x00000000004fa0b4 in read_char (used_mouse_menu=<optimised out>,
prev_event=<optimised out>, local_getcjmp=<optimised out>,
end_time=<optimised out>) at keyboard.c:2211
#48 0x00000000004fa0b4 in read_char (commandflag=commandflag@entry=0,
map=map@entry=0, prev_event=prev_event@entry=0,
used_mouse_menu=used_mouse_menu@entry=0x0, end_time=0x7fff037706f0) at
keyboard.c:2799
---Type <return> to continue, or q <return> to quit---
#49 0x0000000000580baf in read_filtered_event (no_switch_frame=false,
ascii_required=false, error_nonascii=false, input_method=<optimised out>,
seconds=<optimised out>) at lread.c:614
#50 0x0000000000562e1f in Ffuncall (nargs=4, args=args@entry=0x7fff03770810)
at eval.c:2700
#51 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>, args_template=<optimised
out>, nargs=nargs@entry=1, args=<optimised out>, args@entry=0x877d4c
<pure+126988>) at bytecode.c:880
#52 0x0000000000562976 in funcall_lambda (fun=140733251521104,
nargs=nargs@entry=1, arg_vector=0x877d4c <pure+126988>,
    arg_vector@entry=0x7fff037709b8) at eval.c:2855
#53 0x0000000000562c3b in Ffuncall (nargs=2, args=args@entry=0x7fff037709b0)
at eval.c:2754
#54 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>, args_template=<optimised
out>, nargs=nargs@entry=0, args=<optimised out>, args@entry=0x3dd8da4) at
bytecode.c:880
#55 0x0000000000562976 in funcall_lambda (fun=140733251521824,
nargs=nargs@entry=0, arg_vector=0x3dd8da4,
    arg_vector@entry=0x7fff03770c98) at eval.c:2855
#56 0x0000000000562c3b in Ffuncall (nargs=nargs@entry=1,
args=args@entry=0x7fff03770c90)
at eval.c:2754
#57 0x00000000005641bc in Fapply (nargs=2, args=0x7fff03770c90) at
eval.c:2274
#58 0x0000000000562d41 in Ffuncall (nargs=3, args=args@entry=0x7fff03770c88)
at eval.c:2673
#59 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>,
args_template=args_template@entry=0, nargs=nargs@entry=0, args=<optimised
out>, args@entry=0x0) at bytecode.c:880
#60 0x000000000056283f in funcall_lambda (fun=10146693, nargs=nargs@entry=1,
arg_vector=arg_vector@entry=0x7fff03770ea8)
    at eval.c:2921
#61 0x0000000000562c3b in Ffuncall (nargs=nargs@entry=2,
args=args@entry=0x7fff03770ea0)
at eval.c:2754
#62 0x0000000000562f3a in call1 (fn=fn@entry=45264, arg1=arg1@entry=80505365)
at eval.c:2552
#63 0x00000000004f49c8 in timer_check (idle_timers=<optimised out>,
timers=<optimised out>) at keyboard.c:4427
#64 0x00000000004f49c8 in timer_check () at keyboard.c:4489
#65 0x00000000004f4d89 in readable_events (flags=flags@entry=1) at
keyboard.c:3328
#66 0x00000000004f6608 in get_input_pending (flags=flags@entry=1) at
keyboard.c:6725
#67 0x00000000004f8d78 in detect_input_pending_run_timers
(do_display=do_display@entry=true) at keyboard.c:9862
#68 0x00000000005a2abb in wait_reading_process_output
(time_limit=time_limit@entry=30, nsecs=nsecs@entry=0,
read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true,
wait_for_cell=wait_for_cell@entry=0, wait_proc=wait_proc@entry=0x0,
just_wait_proc=0) at process.c:4958
#69 0x0000000000422e12 in sit_for (timeout=<optimised out>,
reading=reading@entry=true, display_option=display_option@entry=1) at
dispnew.c:5762
#70 0x00000000004fb273 in read_char (commandflag=commandflag@entry=1,
map=map@entry=94322451, prev_event=0,
used_mouse_menu=used_mouse_menu@entry=0x7fff03771b4b,
end_time=end_time@entry=0x0) at keyboard.c:2714
#71 0x00000000004fbeda in read_key_sequence
(keybuf=keybuf@entry=0x7fff03771c20,
prompt=prompt@entry=0, dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true,
prevent_redisplay=prevent_redisplay@entry=false, bufsize=30) at
keyboard.c:9063
#72 0x00000000004fdb26 in command_loop_1 () at keyboard.c:1365
#73 0x00000000005615b2 in internal_condition_case (bfun=bfun@entry=0x4fd920
<command_loop_1>, handlers=handlers@entry=19056, hfun=hfun@entry=0x4f4080
<cmd_error>) at eval.c:1309
#74 0x00000000004ef54c in command_loop_2 (ignore=ignore@entry=0) at
keyboard.c:1107
#75 0x0000000000561553 in internal_catch (tag=tag@entry=45840,
func=func@entry=0x4ef530 <command_loop_2>, arg=arg@entry=0)
    at eval.c:1074
#76 0x00000000004ef509 in command_loop () at keyboard.c:1086
#77 0x00000000004f3c77 in recursive_edit_1 () at keyboard.c:692
#78 0x00000000004f3fb8 in Frecursive_edit () at keyboard.c:763
#79 0x0000000000418dfe in main (argc=1, argv=0x7fff03771fa8) at emacs.c:1626
(gdb)

​I tried ​building the current emacs-25 branch with ./configure
--with-xwidgets --with-cairo --with-modules, I get a different crash:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f1fd486a2a9 in raise (sig=sig@entry=11) at
../sysdeps/unix/sysv/linux/pt-raise.c:35
35 ../sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f1fdd77ab00 (LWP 2411))]
(gdb) where
#0  0x00007f1fd486a2a9 in raise (sig=sig@entry=11) at
../sysdeps/unix/sysv/linux/pt-raise.c:35
#1  0x00000000004f11c4 in terminate_due_to_signal (sig=sig@entry=11,
backtrace_limit=backtrace_limit@entry=40) at emacs.c:381
#2  0x000000000050901e in handle_fatal_signal (sig=sig@entry=11) at
sysdep.c:1601
#3  0x0000000000509243 in deliver_thread_signal (sig=sig@entry=11,
handler=0x509010 <handle_fatal_signal>) at sysdep.c:1575
#4  0x00000000005092af in handle_sigsegv (sig=11) at sysdep.c:1613
#5  0x00000000005092af in handle_sigsegv (sig=11, siginfo=<optimised out>,
arg=<optimised out>) at sysdep.c:1695
#6  0x00007f1fd486a3d0 in <signal handler called> () at
/lib/x86_64-linux-gnu/libpthread.so.0
#7  0x000000000056dd24 in sxhash (y=<error reading variable: Cannot access
memory at address 0x0>, x=0) at lisp.h:2025
#8  0x000000000056dd24 in sxhash (len=<optimised out>, ptr=<optimised out>)
at fns.c:4246
#9  0x000000000056dd24 in sxhash (len=<optimised out>, ptr=<optimised out>)
at fns.c:4258
#10 0x000000000056dd24 in sxhash (obj=<optimised out>, depth=depth@entry=1)
at fns.c:4371
#11 0x000000000056dd8e in sxhash (depth=1, obj=<optimised out>) at
fns.c:4296
#12 0x000000000056dd8e in sxhash (depth=0, list=12657603) at fns.c:4298
#13 0x000000000056dd8e in sxhash (obj=<optimised out>, depth=0) at
fns.c:4391
#14 0x00000000005700f1 in hash_lookup (h=h@entry=0x123d968,
key=key@entry=12657603,
hash=hash@entry=0x0) at fns.c:3944
#15 0x00000000005701c6 in Fgethash (key=key@entry=12657603, table=19126637,
dflt=dflt@entry=0) at fns.c:4621
#16 0x00000000005c4462 in ftfont_lookup_cache (key=12657603,
cache_for=cache_for@entry=FTFONT_CACHE_FOR_FACE) at ftfont.c:375
#17 0x00000000005c557e in ftfont_close (font=0x13399f0) at ftfont.c:1329
#18 0x000000000054964d in sweep_vectors () at alloc.c:3219
#19 0x000000000054d747 in Fgarbage_collect () at alloc.c:6981
#20 0x000000000054d747 in Fgarbage_collect (end=0x7ffe7d9773f8) at
alloc.c:5795
#21 0x000000000054d747 in Fgarbage_collect () at alloc.c:5979
#22 0x0000000000564b54 in Ffuncall () at lisp.h:4656
#23 0x0000000000564b54 in Ffuncall (nargs=nargs@entry=2,
args=args@entry=0x7ffe7d9775c0)
at eval.c:2648
#24 0x0000000000564f7a in call1 (fn=fn@entry=21648, arg1=arg1@entry=71809572)
at eval.c:2557
#25 0x0000000000588064 in readevalloop (readcharfun=readcharfun@entry=24384,
stream=stream@entry=0x447bd50, sourcename=sourcename@entry=71809572,
printflag=printflag@entry=false, unibyte=unibyte@entry=0,
readfun=readfun@entry=0, start=0, end=0)
    at lread.c:1830
#26 0x000000000058874c in Fload (file=9181396, noerror=noerror@entry=0,
nomessage=nomessage@entry=44784, nosuffix=nosuffix@entry=0,
must_suffix=<optimised out>, must_suffix@entry=44784) at lread.c:1335
#27 0x000000000056658f in Fautoload_do_load (fundef=9508451,
funname=4814608, macro_only=0) at eval.c:1962
#28 0x0000000000564e5f in Ffuncall (nargs=3, args=args@entry=0x7ffe7d977940)
at eval.c:2705
#29 0x000000000059c8d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>, args_template=<optimised
out>, nargs=nargs@entry=1, args=<optimised out>, args@entry=0x4131664) at
bytecode.c:880
#30 0x00000000005649b6 in funcall_lambda (fun=140731005500480,
nargs=nargs@entry=1, arg_vector=0x4131664,
    arg_vector@entry=0x7ffe7d977b98) at eval.c:2860
#31 0x0000000000564c7b in Ffuncall (nargs=2, args=args@entry=0x7ffe7d977b90)
at eval.c:2759
#32 0x000000000059c8d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>, args_template=<optimised
out>, nargs=nargs@entry=10, args=<optimised out>, args@entry=0x4130fc4) at
bytecode.c:880
#33 0x00000000005649b6 in funcall_lambda (fun=140731005501328,
nargs=nargs@entry=10, arg_vector=0x4130fc4,
    arg_vector@entry=0x7ffe7d977d58) at eval.c:2860
#34 0x0000000000564c7b in Ffuncall (nargs=nargs@entry=11,
args=0x7ffe7d977d50) at eval.c:2759
#35 0x0000000000566060 in Fapply (nargs=<optimised out>,
args=0x7ffe7d977f10) at eval.c:2326
#36 0x0000000000564d81 in Ffuncall (nargs=3, args=args@entry=0x7ffe7d977f08)
at eval.c:2678
#37 0x000000000059c8d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>, args_template=<optimised
out>, nargs=nargs@entry=0, args=<optimised out>, args@entry=0x41306c4) at
bytecode.c:880
#38 0x00000000005649b6 in funcall_lambda (fun=140731005501776,
nargs=nargs@entry=0, arg_vector=0x41306c4,
    arg_vector@entry=0x7ffe7d9780c0) at eval.c:2860
#39 0x0000000000564c7b in Ffuncall (nargs=1, args=args@entry=0x7ffe7d9780b8)
at eval.c:2759
#40 0x000000000059c8d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>, args_template=<optimised
out>, nargs=nargs@entry=0, args=<optimised out>, args@entry=0x41303f4) at
bytecode.c:880
#41 0x00000000005649b6 in funcall_lambda (fun=140731005502496,
nargs=nargs@entry=0, arg_vector=0x41303f4,
    arg_vector@entry=0x7ffe7d978398) at eval.c:2860
#42 0x0000000000564c7b in Ffuncall (nargs=nargs@entry=1,
args=args@entry=0x7ffe7d978390)
at eval.c:2759
#43 0x00000000005661fc in Fapply (nargs=2, args=0x7ffe7d978390) at
eval.c:2279
#44 0x0000000000564d81 in Ffuncall (nargs=3, args=args@entry=0x7ffe7d978388)
at eval.c:2678
#45 0x000000000059c8d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>,
args_template=args_template@entry=0, nargs=nargs@entry=0, args=<optimised
out>, args@entry=0x0) at bytecode.c:880
#46 0x000000000056487f in funcall_lambda (fun=10158805, nargs=nargs@entry=1,
arg_vector=arg_vector@entry=0x7ffe7d9785a8)
    at eval.c:2926
#47 0x0000000000564c7b in Ffuncall (nargs=nargs@entry=2,
args=args@entry=0x7ffe7d9785a0)
at eval.c:2759
#48 0x0000000000564f7a in call1 (fn=fn@entry=45600, arg1=arg1@entry=89586453)
at eval.c:2557
#49 0x00000000004f6a98 in timer_check (idle_timers=<optimised out>,
timers=<optimised out>) at keyboard.c:4427
#50 0x00000000004f6a98 in timer_check () at keyboard.c:4489
#51 0x00000000004f6e59 in readable_events (flags=flags@entry=1) at
keyboard.c:3328
#52 0x00000000004f86d8 in get_input_pending (flags=flags@entry=1) at
keyboard.c:6725
#53 0x00000000004fadb8 in detect_input_pending_run_timers
(do_display=do_display@entry=true) at keyboard.c:9862
#54 0x00000000005a7d9b in wait_reading_process_output
(time_limit=time_limit@entry=30, nsecs=nsecs@entry=0,
read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true,
wait_for_cell=wait_for_cell@entry=0, wait_proc=wait_proc@entry=0x0,
just_wait_proc=0) at process.c:4958
#55 0x0000000000423b12 in sit_for (timeout=<optimised out>,
reading=reading@entry=true, display_option=display_option@entry=1) at
dispnew.c:5762
---Type <return> to continue, or q <return> to quit---
#56 0x00000000004fd092 in read_char (commandflag=commandflag@entry=1,
map=map@entry=40733251, prev_event=0,
used_mouse_menu=used_mouse_menu@entry=0x7ffe7d97924b,
end_time=end_time@entry=0x0) at keyboard.c:2714
#57 0x00000000004fdf2a in read_key_sequence
(keybuf=keybuf@entry=0x7ffe7d979320,
prompt=prompt@entry=0, dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true,
prevent_redisplay=prevent_redisplay@entry=false, bufsize=30) at
keyboard.c:9063
#58 0x00000000004ffb76 in command_loop_1 () at keyboard.c:1365
#59 0x00000000005635f2 in internal_condition_case (bfun=bfun@entry=0x4ff970
<command_loop_1>, handlers=handlers@entry=18912, hfun=hfun@entry=0x4f6160
<cmd_error>) at eval.c:1314
#60 0x00000000004f160c in command_loop_2 (ignore=ignore@entry=0) at
keyboard.c:1107
#61 0x0000000000563593 in internal_catch (tag=tag@entry=46176,
func=func@entry=0x4f15f0 <command_loop_2>, arg=arg@entry=0)
    at eval.c:1079
#62 0x00000000004f15c9 in command_loop () at keyboard.c:1086
#63 0x00000000004f5d57 in recursive_edit_1 () at keyboard.c:692
#64 0x00000000004f6098 in Frecursive_edit () at keyboard.c:763
#65 0x000000000041a7ce in main (argc=1, argv=0x7ffe7d9796a8) at emacs.c:1626

In both cases, the crash occurs while Emacs is lazy-loading my desktop. I
can't tell exactly what it's doing, but it appears to be about the same
place each time.

The crash happens most times, but at least once I started emacs and it
didn't crash.​​

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 27182 bytes --]

bug#24640: Crashes in 25.1

[Eli Zaretskii]

> From: Reuben Thomas <rrt@sc3d.org>
> Date: Sat, 8 Oct 2016 00:12:26 +0100
> 
> In both cases, the crash occurs while Emacs is lazy-loading my desktop.

What does "lazy-loading" mean in this context?

> I can't tell exactly what it's doing, but it appears to be about the
> same place each time.

If you run Emacs under GDB, and source the src/.gdbinit file provided
in the source tree, the backtrace command will automatically try to
produce a Lisp-level backtrace as well.  That could be helpful.

This string in the 1st backtrace you show could help figure out what
form was being evaluated:

  #41 0x000000000059af2d in read_process_output (coding=0x53b3920, nbytes=652, chars=0x7fff0376eaa0
  "Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\\\\begin{
  <-- HERE tex}(.*?)\\\\end{tex}/ at /usr/bin/texify line 521.\nUnescaped left brace in regex is depre"..., p=0x287)
  at process.c:5440

The SIGSEGV happens here:

      nextsym:
	if (ptr->gcmarkbit)  <<<<<<<<<<<<<<<<<<
	  break;

So the value of 'ptr' there (frame 20 in the 1st backtrace) is of
interest.

> ​I tried ​building the current emacs-25 branch with ./configure --with-xwidgets --with-cairo --with-modules, I get
> a different crash:
> [...]
> #6 0x00007f1fd486a3d0 in <signal handler called> () at /lib/x86_64-linux-gnu/libpthread.so.0
> #7 0x000000000056dd24 in sxhash (y=<error reading variable: Cannot access memory at address 0x0>,
> x=0) at lisp.h:2025
> #8 0x000000000056dd24 in sxhash (len=<optimised out>, ptr=<optimised out>) at fns.c:4246

This part of the backtrace, right before the SIGSEGV, makes no sense:
the code at line 2025 of lisp.h does bitwise operations on scalar
values, and y is one such scalar value.  Please build without
optimizations, that would make the backtraces more reliable and
detailed.

Was the Ubuntu package also compiled with Cairo?  (I cannot figure out
the build details from the URL you provided, and your report lacks the
details collected by "M-x report-emacs-bug".)  If so, please try
building without Cairo, as that option is not yet recommended for
prime time.

Thanks.

bug#24640: Crashes in 25.1

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 5070 bytes --]

On 8 October 2016 at 06:53, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Reuben Thomas <rrt@sc3d.org>
> > Date: Sat, 8 Oct 2016 00:12:26 +0100
> >
> > In both cases, the crash occurs while Emacs is lazy-loading my desktop.
>
> What does "lazy-loading" mean in this context?
>

​When desktop(.el) is run at startup, it loads a fixed number of buffers
immediately, then lazy-loads the rest. It's during the lazy loading that
the crash happens.​


> > I can't tell exactly what it's doing, but it appears to be about the
> > same place each time.
>
> If you run Emacs under GDB, and source the src/.gdbinit file provided
> in the source tree, the backtrace command will automatically try to
> produce a Lisp-level backtrace as well.  That could be helpful.
>

​Fortunately(!) it is still crashing the same way. Here you go:​

[New Thread 0x7fffe5960700 (LWP 19613)]
[New Thread 0x7fffe4cf1700 (LWP 19614)]
[New Thread 0x7fffdfd2d700 (LWP 19615)]

Thread 1 "emacs25" received signal SIGSEGV, Segmentation fault.
mark_object (arg=<optimised out>) at alloc.c:6488
6488    alloc.c: No such file or directory.
(gdb) bt 1
#0  0x000000000054aa44 in mark_object (arg=<optimised out>) at alloc.c:6488
#1  0x000000000054a8fe in mark_object (arg=<optimised out>) at alloc.c:6452

Lisp Backtrace:
"Automatic GC" (0x0)
"process-file" (0xffff9ea0)
"apply" (0xffff9e98)
"vc-git--call" (0xffffa188)
"apply" (0xffffa180)
"vc-git--out-ok" (0xffffa318)
"apply" (0xffffa488)
"vc-git--run-command-string" (0xffffa638)
"vc-git--symbolic-ref" (0xffffa800)
"vc-git-mode-line-string" (0xffffab08)
"apply" (0xffffab00)
"vc-call-backend" (0xffffad20)
"vc-mode-line" (0xffffaf60)
"vc-refresh-state" (0xffffb1a8)
"auto-revert-handler" (0xffffb388)
"auto-revert-buffers" (0xffffb530)
"auto-revert-mode" (0xffffb7b0)
"desktop-create-buffer" (0xffffb948)
"apply" (0xffffbb00)
"desktop-lazy-create-buffer" (0xffffbcb0)
"desktop-idle-create-buffers" (0xffffbf88)
"apply" (0xffffbf80)
"timer-event-handler" (0xffffc198)​


> This part of the backtrace, right before the SIGSEGV, makes no sense:
> the code at line 2025 of lisp.h does bitwise operations on scalar
> values, and y is one such scalar value.  Please build without
> optimizations, that would make the backtraces more reliable and
> detailed.
>

​For now I'll concentrate on the Ubuntu build; I can go back to the
self-build later; I've reconfigured the source tree​ with default options.


> Was the Ubuntu package also compiled with Cairo?


​I had a look at the source package, and it doesn't build with
--with-cairo, so no.

On 8 October 2016 at 06:53, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Reuben Thomas <rrt@sc3d.org>
> > Date: Sat, 8 Oct 2016 00:12:26 +0100
> >
> > In both cases, the crash occurs while Emacs is lazy-loading my desktop.
>
> What does "lazy-loading" mean in this context?
>
> > I can't tell exactly what it's doing, but it appears to be about the
> > same place each time.
>
> If you run Emacs under GDB, and source the src/.gdbinit file provided
> in the source tree, the backtrace command will automatically try to
> produce a Lisp-level backtrace as well.  That could be helpful.
>
> This string in the 1st backtrace you show could help figure out what
> form was being evaluated:
>
>   #41 0x000000000059af2d in read_process_output (coding=0x53b3920,
> nbytes=652, chars=0x7fff0376eaa0
>   "Unescaped left brace in regex is deprecated, passed through in regex;
> marked by <-- HERE in m/\\\\begin{
>   <-- HERE tex}(.*?)\\\\end{tex}/ at /usr/bin/texify line 521.\nUnescaped
> left brace in regex is depre"..., p=0x287)
>   at process.c:5440
>
> The SIGSEGV happens here:
>
>       nextsym:
>         if (ptr->gcmarkbit)  <<<<<<<<<<<<<<<<<<
>           break;
>
> So the value of 'ptr' there (frame 20 in the 1st backtrace) is of
> interest.
>
> > ​I tried ​building the current emacs-25 branch with ./configure
> --with-xwidgets --with-cairo --with-modules, I get
> > a different crash:
> > [...]
> > #6 0x00007f1fd486a3d0 in <signal handler called> () at
> /lib/x86_64-linux-gnu/libpthread.so.0
> > #7 0x000000000056dd24 in sxhash (y=<error reading variable: Cannot
> access memory at address 0x0>,
> > x=0) at lisp.h:2025
> > #8 0x000000000056dd24 in sxhash (len=<optimised out>, ptr=<optimised
> out>) at fns.c:4246
>
> This part of the backtrace, right before the SIGSEGV, makes no sense:
> the code at line 2025 of lisp.h does bitwise operations on scalar
> values, and y is one such scalar value.  Please build without
> optimizations, that would make the backtraces more reliable and
> detailed.
>
> Was the Ubuntu package also compiled with Cairo?  (I cannot figure out
> the build details from the URL you provided, and your report lacks the
> details collected by "M-x report-emacs-bug".)  If so, please try
> building without Cairo, as that option is not yet recommended for
> prime time.
>
> Thanks.
>



-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 7386 bytes --]

bug#24640: Crashes in 25.1

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]

On 8 October 2016 at 06:53, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Reuben Thomas <rrt@sc3d.org>
> > Date: Sat, 8 Oct 2016 00:12:26 +0100
> >
> > In both cases, the crash occurs while Emacs is lazy-loading my desktop.
>
> What does "lazy-loading" mean in this context?
>
> > I can't tell exactly what it's doing, but it appears to be about the
> > same place each time.
>
> If you run Emacs under GDB, and source the src/.gdbinit file provided
> in the source tree, the backtrace command will automatically try to
> produce a Lisp-level backtrace as well.  That could be helpful.
>
> This string in the 1st backtrace you show could help figure out what
> form was being evaluated:
>
>   #41 0x000000000059af2d in read_process_output (coding=0x53b3920,
> nbytes=652, chars=0x7fff0376eaa0
>   "Unescaped left brace in regex is deprecated, passed through in regex;
> marked by <-- HERE in m/\\\\begin{
>   <-- HERE tex}(.*?)\\\\end{tex}/ at /usr/bin/texify line 521.\nUnescaped
> left brace in regex is depre"..., p=0x287)
>   at process.c:5440
>
> The SIGSEGV happens here:
>
>       nextsym:
>         if (ptr->gcmarkbit)  <<<<<<<<<<<<<<<<<<
>           break;
>
> So the value of 'ptr' there (frame 20 in the 1st backtrace) is of
> interest.
>

​The current backtrace seems to have crashed at a different point, and
doesn't even include this line, but this time I've kept the gdb session
running in case I can tell you anything else of ​

​interest.​

[-- Attachment #2: Type: text/html, Size: 2175 bytes --]

bug#24640: Crashes in 25.1

[Eli Zaretskii]

> From: Reuben Thomas <rrt@sc3d.org>
> Date: Sat, 8 Oct 2016 14:30:41 +0100
> Cc: 24640@debbugs.gnu.org
> 
>  So the value of 'ptr' there (frame 20 in the 1st backtrace) is of
>  interest.
> 
> ​The current backtrace seems to have crashed at a different point, and doesn't even include this line, but this
> time I've kept the gdb session running in case I can tell you anything else of ​
> ​interest.​

Well, can you tell why it crashed this time?  IOW, what was the
immediate cause of SIGSEGV?

bug#24640: Crashes in 25.1

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

​O​
n 8 October 2016 at 15:30, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Reuben Thomas <rrt@sc3d.org>
> > Date: Sat, 8 Oct 2016 14:30:41 +0100
> > Cc: 24640@debbugs.gnu.org
> >
> >  So the value of 'ptr' there (frame 20 in the 1st backtrace) is of
> >  interest.
> >
> > ​The current backtrace seems to have crashed at a different point, and
> doesn't even include this line, but this
> > time I've kept the gdb session running in case I can tell you anything
> else of ​
> > ​interest.​
>
> Well, can you tell why it crashed this time?  IOW, what was the
> immediate cause of SIGSEGV?
>

​Exactly the same as before: crashed while lazy-reloading in desktop.el. At
the same point as before, as far as I can tell.
​​

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1560 bytes --]

bug#24640: Crashes in 25.1

[Eli Zaretskii]

> From: Reuben Thomas <rrt@sc3d.org>
> Date: Sat, 8 Oct 2016 16:26:30 +0100
> Cc: 24640@debbugs.gnu.org
> 
>  Well, can you tell why it crashed this time? IOW, what was the
>  immediate cause of SIGSEGV?
> 
> ​Exactly the same as before: crashed while lazy-reloading in desktop.el. At the same point as before, as far as
> I can tell.

No, I meant the immediate cause of SIGSEGV, one frame below the one
which invokes the signal handler.  There must be some bad data there,
what it is?

bug#24640: Crashes in 25.1

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 12986 bytes --]

On 8 October 2016 at 16:34, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Reuben Thomas <rrt@sc3d.org>
> > Date: Sat, 8 Oct 2016 16:26:30 +0100
> > Cc: 24640@debbugs.gnu.org
> >
> >  Well, can you tell why it crashed this time? IOW, what was the
> >  immediate cause of SIGSEGV?
> >
> > ​Exactly the same as before: crashed while lazy-reloading in desktop.el.
> At the same point as before, as far as
> > I can tell.
>
> No, I meant the immediate cause of SIGSEGV, one frame below the one
> which invokes the signal handler.  There must be some bad data there,
> what it is?
>

​Here's the current C backtrace:

#0  0x000000000054aa44 in mark_object (arg=<optimised out>) at alloc.c:6488
#1  0x000000000054a8fe in mark_object (arg=<optimised out>) at alloc.c:6452
#2  0x000000000054a8fe in mark_object (arg=<optimised out>) at alloc.c:6452
#3  0x000000000054a9cb in mark_object (arg=<optimised out>) at alloc.c:6539
#4  0x000000000054a9cb in mark_object (arg=<optimised out>) at alloc.c:6539
#5  0x000000000054b20c in Fgarbage_collect (end=0x7fffffff9a28) at
alloc.c:5745
#6  0x000000000054b20c in Fgarbage_collect () at alloc.c:5979
#7  0x000000000059979e in exec_byte_code () at lisp.h:4656
#8  0x000000000059979e in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>, args_template=<optimised
out>, nargs=nargs@entry=6, args=<optimised out>, args@entry=0x937914
<pure+912340>) at bytecode.c:714
#9  0x0000000000562976 in funcall_lambda (fun=140737488330544,
nargs=nargs@entry=6, arg_vector=0x937914 <pure+912340>,
    arg_vector@entry=0x7fffffff9ea0) at eval.c:2855
#10 0x0000000000562c3b in Ffuncall (nargs=nargs@entry=7,
args=args@entry=0x7fffffff9e98)
at eval.c:2754
#11 0x00000000005641d4 in Fapply (nargs=7, args=0x7fffffff9e98) at
eval.c:2278
#12 0x0000000000562d41 in Ffuncall (nargs=8, args=args@entry=0x7fffffff9e90)
at eval.c:2673
#13 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>, args_template=<optimised
out>, nargs=nargs@entry=3, args=<optimised out>, args@entry=0x236a3d4) at
bytecode.c:880
#14 0x0000000000562976 in funcall_lambda (fun=140737488331264,
nargs=nargs@entry=3, arg_vector=0x236a3d4,
    arg_vector@entry=0x7fffffffa188) at eval.c:2855
#15 0x0000000000562c3b in Ffuncall (nargs=nargs@entry=4,
args=args@entry=0x7fffffffa180)
at eval.c:2754
#16 0x00000000005641d4 in Fapply (nargs=4, args=0x7fffffffa180) at
eval.c:2278
#17 0x0000000000562d41 in Ffuncall (nargs=5, args=args@entry=0x7fffffffa178)
at eval.c:2673
#18 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>, args_template=<optimised
out>, nargs=nargs@entry=2, args=<optimised out>, args@entry=0x240e244) at
bytecode.c:880
#19 0x0000000000562976 in funcall_lambda (fun=140737488332048,
nargs=nargs@entry=2, arg_vector=0x240e244,
    arg_vector@entry=0x7fffffffa318) at eval.c:2855
#20 0x0000000000562c3b in Ffuncall (nargs=nargs@entry=3,
args=0x7fffffffa310) at eval.c:2754
#21 0x0000000000564020 in Fapply (nargs=<optimised out>,
args=0x7fffffffa488) at eval.c:2321
#22 0x0000000000562d41 in Ffuncall (nargs=3, args=args@entry=0x7fffffffa480)
at eval.c:2673
#23 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>, args_template=<optimised
out>, nargs=nargs@entry=3, args=<optimised out>, args@entry=0x22fa6f4) at
bytecode.c:880
#24 0x0000000000562976 in funcall_lambda (fun=140737488332496,
nargs=nargs@entry=3, arg_vector=0x22fa6f4,
    arg_vector@entry=0x7fffffffa638) at eval.c:2855
#25 0x0000000000562c3b in Ffuncall (nargs=4, args=args@entry=0x7fffffffa630)
at eval.c:2754
#26 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>, args_template=<optimised
out>, nargs=nargs@entry=1, args=<optimised out>, args@entry=0x2b7d384) at
bytecode.c:880
#27 0x0000000000562976 in funcall_lambda (fun=140737488332992,
nargs=nargs@entry=1, arg_vector=0x2b7d384,
    arg_vector@entry=0x7fffffffa800) at eval.c:2855
#28 0x0000000000562c3b in Ffuncall (nargs=2, args=args@entry=0x7fffffffa7f8)
at eval.c:2754
#29 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>, args_template=<optimised
out>, nargs=nargs@entry=1, args=<optimised out>, args@entry=0x2b7d564) at
bytecode.c:880
#30 0x0000000000562976 in funcall_lambda (fun=140737488333712,
nargs=nargs@entry=1, arg_vector=0x2b7d564,
    arg_vector@entry=0x7fffffffab08) at eval.c:2855
#31 0x0000000000562c3b in Ffuncall (nargs=nargs@entry=2,
args=args@entry=0x7fffffffab00)
at eval.c:2754
#32 0x00000000005641d4 in Fapply (nargs=2, args=0x7fffffffab00) at
eval.c:2278
#33 0x0000000000562d41 in Ffuncall (nargs=3, args=args@entry=0x7fffffffaaf8)
at eval.c:2673
#34 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>,
args_template=args_template@entry=0, nargs=nargs@entry=0, args=<optimised
out>, args@entry=0x0) at bytecode.c:880
#35 0x000000000056283f in funcall_lambda (fun=10562237, nargs=nargs@entry=3,
arg_vector=arg_vector@entry=0x7fffffffad20)
    at eval.c:2921
#36 0x0000000000562c3b in Ffuncall (nargs=4, args=args@entry=0x7fffffffad18)
at eval.c:2754
#37 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>,
args_template=args_template@entry=0, nargs=nargs@entry=0, args=<optimised
out>, args@entry=0x0) at bytecode.c:880
#38 0x000000000056283f in funcall_lambda (fun=10569021, nargs=nargs@entry=2,
arg_vector=arg_vector@entry=0x7fffffffaf60)
    at eval.c:2921
#39 0x0000000000562c3b in Ffuncall (nargs=3, args=args@entry=0x7fffffffaf58)
at eval.c:2754
#40 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>,
args_template=args_template@entry=0, nargs=nargs@entry=0, args=<optimised
out>, args@entry=0x0) at bytecode.c:880
#41 0x000000000056283f in funcall_lambda (fun=10570821, nargs=nargs@entry=0,
arg_vector=arg_vector@entry=0x7fffffffb1a8)
    at eval.c:2921
#42 0x0000000000562c3b in Ffuncall (nargs=1, args=args@entry=0x7fffffffb1a0)
at eval.c:2754
#43 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>, args_template=<optimised
out>, nargs=nargs@entry=0, args=<optimised out>, args@entry=0x2e5f674) at
bytecode.c:880
#44 0x0000000000562976 in funcall_lambda (fun=140737488335872,
nargs=nargs@entry=0, arg_vector=0x2e5f674,
    arg_vector@entry=0x7fffffffb388) at eval.c:2855
#45 0x0000000000562c3b in Ffuncall (nargs=1, args=args@entry=0x7fffffffb380)
at eval.c:2754
#46 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>, args_template=<optimised
out>, nargs=nargs@entry=0, args=<optimised out>, args@entry=0x2e605a4) at
bytecode.c:880
#47 0x0000000000562976 in funcall_lambda (fun=140737488336320,
nargs=nargs@entry=0, arg_vector=0x2e605a4,
    arg_vector@entry=0x7fffffffb530) at eval.c:2855
#48 0x0000000000562c3b in Ffuncall (nargs=1, args=args@entry=0x7fffffffb528)
at eval.c:2754
#49 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>, args_temp---Type <return>
to continue, or q <return> to quit---
late=<optimised out>, nargs=nargs@entry=1, args=<optimised out>,
args@entry=0x2e56384)
at bytecode.c:880
#50 0x0000000000562976 in funcall_lambda (fun=140737488336944,
nargs=nargs@entry=1, arg_vector=0x2e56384,
    arg_vector@entry=0x7fffffffb7b0) at eval.c:2855
#51 0x0000000000562c3b in Ffuncall (nargs=2, args=args@entry=0x7fffffffb7a8)
at eval.c:2754
#52 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>, args_template=<optimised
out>, nargs=nargs@entry=10, args=<optimised out>, args@entry=0x2ca3794) at
bytecode.c:880
#53 0x0000000000562976 in funcall_lambda (fun=140737488337792,
nargs=nargs@entry=10, arg_vector=0x2ca3794,
    arg_vector@entry=0x7fffffffb948) at eval.c:2855
#54 0x0000000000562c3b in Ffuncall (nargs=nargs@entry=11,
args=0x7fffffffb940) at eval.c:2754
#55 0x0000000000564020 in Fapply (nargs=<optimised out>,
args=0x7fffffffbb00) at eval.c:2321
#56 0x0000000000562d41 in Ffuncall (nargs=3, args=args@entry=0x7fffffffbaf8)
at eval.c:2673
#57 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>, args_template=<optimised
out>, nargs=nargs@entry=0, args=<optimised out>, args@entry=0x2ca8ab4) at
bytecode.c:880
#58 0x0000000000562976 in funcall_lambda (fun=140737488338240,
nargs=nargs@entry=0, arg_vector=0x2ca8ab4,
    arg_vector@entry=0x7fffffffbcb0) at eval.c:2855
#59 0x0000000000562c3b in Ffuncall (nargs=1, args=args@entry=0x7fffffffbca8)
at eval.c:2754
#60 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>, args_template=<optimised
out>, nargs=nargs@entry=0, args=<optimised out>, args@entry=0x2caaed4) at
bytecode.c:880
#61 0x0000000000562976 in funcall_lambda (fun=140737488338960,
nargs=nargs@entry=0, arg_vector=0x2caaed4,
    arg_vector@entry=0x7fffffffbf88) at eval.c:2855
#62 0x0000000000562c3b in Ffuncall (nargs=nargs@entry=1,
args=args@entry=0x7fffffffbf80)
at eval.c:2754
#63 0x00000000005641bc in Fapply (nargs=2, args=0x7fffffffbf80) at
eval.c:2274
#64 0x0000000000562d41 in Ffuncall (nargs=3, args=args@entry=0x7fffffffbf78)
at eval.c:2673
#65 0x00000000005975d3 in exec_byte_code (bytestr=<optimised out>,
vector=<optimised out>, maxdepth=<optimised out>,
args_template=args_template@entry=0, nargs=nargs@entry=0, args=<optimised
out>, args@entry=0x0) at bytecode.c:880
#66 0x000000000056283f in funcall_lambda (fun=10146693, nargs=nargs@entry=1,
arg_vector=arg_vector@entry=0x7fffffffc198)
    at eval.c:2921
#67 0x0000000000562c3b in Ffuncall (nargs=nargs@entry=2,
args=args@entry=0x7fffffffc190)
at eval.c:2754
#68 0x0000000000562f3a in call1 (fn=fn@entry=45264, arg1=arg1@entry=46400381)
at eval.c:2552
#69 0x00000000004f49c8 in timer_check (idle_timers=<optimised out>,
timers=<optimised out>) at keyboard.c:4427
#70 0x00000000004f49c8 in timer_check () at keyboard.c:4489
#71 0x00000000004f4d89 in readable_events (flags=flags@entry=1) at
keyboard.c:3328
#72 0x00000000004f6608 in get_input_pending (flags=flags@entry=1) at
keyboard.c:6725
#73 0x00000000004f8d78 in detect_input_pending_run_timers
(do_display=do_display@entry=true) at keyboard.c:9862
#74 0x00000000005a2abb in wait_reading_process_output
(time_limit=time_limit@entry=30, nsecs=nsecs@entry=0,
read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true,
wait_for_cell=wait_for_cell@entry=0, wait_proc=wait_proc@entry=0x0,
just_wait_proc=0) at process.c:4958
#75 0x0000000000422e12 in sit_for (timeout=<optimised out>,
reading=reading@entry=true, display_option=display_option@entry=1) at
dispnew.c:5762
#76 0x00000000004fb273 in read_char (commandflag=commandflag@entry=1,
map=map@entry=76268163, prev_event=0,
used_mouse_menu=used_mouse_menu@entry=0x7fffffffce3b,
end_time=end_time@entry=0x0) at keyboard.c:2714
#77 0x00000000004fbeda in read_key_sequence
(keybuf=keybuf@entry=0x7fffffffcf10,
prompt=prompt@entry=0, dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true,
prevent_redisplay=prevent_redisplay@entry=false, bufsize=30) at
keyboard.c:9063
#78 0x00000000004fdb26 in command_loop_1 () at keyboard.c:1365
#79 0x00000000005615b2 in internal_condition_case (bfun=bfun@entry=0x4fd920
<command_loop_1>, handlers=handlers@entry=19056, hfun=hfun@entry=0x4f4080
<cmd_error>) at eval.c:1309
#80 0x00000000004ef54c in command_loop_2 (ignore=ignore@entry=0) at
keyboard.c:1107
#81 0x0000000000561553 in internal_catch (tag=tag@entry=45840,
func=func@entry=0x4ef530 <command_loop_2>, arg=arg@entry=0)
    at eval.c:1074
#82 0x00000000004ef509 in command_loop () at keyboard.c:1086
#83 0x00000000004f3c77 in recursive_edit_1 () at keyboard.c:692
#84 0x00000000004f3fb8 in Frecursive_edit () at keyboard.c:763
#85 0x0000000000418dfe in main (argc=1, argv=0x7fffffffd298) at emacs.c:1626

​Sorry I didn't post that before, the "bt" command only gives the Lisp
backtrace, and I didn't think to try "where".​
​

​In frame #0, the code reads:

      if (XMISCANY (obj)->gcmarkbit)
        break;

at this point obj is 33, XMISCANY(obj) is 20, and gdb tells me "Cannot
access memory at address 0x20".

​If it helps, I'm happy to arrange some sort of live chat to get through
the debugging process quicker.

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 14647 bytes --]

bug#24640: Crashes in 25.1

[Eli Zaretskii]

> From: Reuben Thomas <rrt@sc3d.org>
> Date: Sat, 8 Oct 2016 23:08:51 +0100
> Cc: 24640@debbugs.gnu.org
> 
> ​In frame #0, the code reads:
> 
> if (XMISCANY (obj)->gcmarkbit)
> break;
> 
> at this point obj is 33, XMISCANY(obj) is 20, and gdb tells me "Cannot access memory at address 0x20".

What do the following commands say in that frame #0:

 (gdb) p obj
 (gdb) xtype

> ​If it helps, I'm happy to arrange some sort of live chat to get through the debugging process quicker.

The only efficient way to speed up debugging (or rather to make sure
it succeeds at all) is for you to come up with a reproducible recipe
and post here all the files needed for reproducing the crashes.

From what I see in the backtraces, your setup fires a timer that runs
some complicated Lisp, and that Lisp somehow corrupts some Lisp
objects, which then cause crashes during GC.  I don't see how this can
be debugged at all, except by someone who actually has this on his/her
machine and knows how to debug these problems.  And the first step is
to stop using an optimized build, because it makes debugging much
harder if not impossible.

If you are willing to try the debugging yourself, there's some advice
in etc/DEBUG (search for "Debugging problems which happen in GC").

Do I understand correctly that this worked for you with Emacs 24.5?

Thanks.

bug#24640: Crashes in 25.1

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]

On 9 October 2016 at 08:05, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Reuben Thomas <rrt@sc3d.org>
> > Date: Sat, 8 Oct 2016 23:08:51 +0100
> > Cc: 24640@debbugs.gnu.org
> >
> > ​In frame #0, the code reads:
> >
> > if (XMISCANY (obj)->gcmarkbit)
> > break;
> >
> > at this point obj is 33, XMISCANY(obj) is 20, and gdb tells me "Cannot
> access memory at address 0x20".
>
> What do the following commands say in that frame #0:
>
>  (gdb) p obj
>  (gdb) xtype
>

(gdb) p obj
$3 = 33
(gdb) xtype
Lisp_Misc
Cannot access memory at address 0x20​

The only efficient way to speed up debugging (or rather to make sure
> it succeeds at all) is for you to come up with a reproducible recipe
> and post here all the files needed for reproducing the crashes.
>

​That would seem to require me to bisect my .desktop and potentially post
dozens of personal files, so doesn't seem feasible.​ I thought it might be
faster for you to drive a debugging session live than to engage in
back-and-forth by email.

From what I see in the backtraces, your setup fires a timer that runs
> some complicated Lisp, and that Lisp somehow corrupts some Lisp
> objects, which then cause crashes during GC.


​You make it sound as though this is some arcane personal setup, when in
fact I am simply using desktop.el!

And the first step is
> to stop using an optimized build, because it makes debugging much
> harder if not impossible.
>

I'll see if, having rebuilt from source without optimisation, the bug still
fires.​

If you are willing to try the debugging yourself, there's some advice
> in etc/DEBUG (search for "Debugging problems which happen in GC").
>

​I'll have a look.​


> Do I understand correctly that this worked for you with Emacs 24.5?
>

​Yes, the identical setup loads fine in 24.5. I've never seen this sort of
crash before.​

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 3621 bytes --]

bug#24640: Crashes in 25.1

[Eli Zaretskii]

> From: Reuben Thomas <rrt@sc3d.org>
> Date: Sun, 9 Oct 2016 08:45:08 +0100
> Cc: 24640@debbugs.gnu.org
> 
>  The only efficient way to speed up debugging (or rather to make sure
>  it succeeds at all) is for you to come up with a reproducible recipe
>  and post here all the files needed for reproducing the crashes.
> 
> ​That would seem to require me to bisect my .desktop and potentially post dozens of personal files, so doesn't
> seem feasible.​

If you just start a fresh session, save its desktop, then restart it,
while using the lazy-load feature, does it start normally?  Maybe all
that's needed is to do this, with no personal files involved.

> I thought it might be faster for you to drive a debugging session live than to engage in
> back-and-forth by email.

It would require me to explain too many things, so it won't be
efficient enough.

>  >From what I see in the backtraces, your setup fires a timer that runs
>  some complicated Lisp, and that Lisp somehow corrupts some Lisp
>  objects, which then cause crashes during GC.
> 
> ​You make it sound as though this is some arcane personal setup, when in fact I am simply using desktop.el!

So do I, but it never crashes for me.  Nor did we have such crash
reports until now.  So there's something you do that I and others
don't, although I didn't mean (and didn't say AFAIK) that it's
something arcane.

>  And the first step is
>  to stop using an optimized build, because it makes debugging much
>  harder if not impossible.
> 
> I'll see if, having rebuilt from source without optimisation, the bug still fires.​
> 
>  If you are willing to try the debugging yourself, there's some advice
>  in etc/DEBUG (search for "Debugging problems which happen in GC").
> 
> ​I'll have a look.​

Thanks.

>  Do I understand correctly that this worked for you with Emacs 24.5?
> 
> ​Yes, the identical setup loads fine in 24.5. I've never seen this sort of crash before.​

Does Emacs crash when restoring a desktop file written by Emacs 24.5,
or only when it restores files written by Emacs 25?

bug#24640: Crashes in 25.1

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]

On 9 October 2016 at 10:57, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Reuben Thomas <rrt@sc3d.org>
> > Date: Sun, 9 Oct 2016 08:45:08 +0100
> > Cc: 24640@debbugs.gnu.org
> >
> >  The only efficient way to speed up debugging (or rather to make sure
> >  it succeeds at all) is for you to come up with a reproducible recipe
> >  and post here all the files needed for reproducing the crashes.
> >
> > ​That would seem to require me to bisect my .desktop and potentially
> post dozens of personal files, so doesn't
> > seem feasible.​
>
> If you just start a fresh session, save its desktop, then restart it,
> while using the lazy-load feature, does it start normally?  Maybe all
> that's needed is to do this, with no personal files involved.
>

​It starts normally, unfortunately.
​​

> >  And the first step is
> >  to stop using an optimized build, because it makes debugging much
> >  harder if not impossible.
> >
> > I'll see if, having rebuilt from source without optimisation, the bug
> still fires.​
>

​I rebuilt with the options suggested in etc/DEBUG, and couldn't get it to
crash.
​ I then tried building with -Og instead of -O0, as suggested in etc/DEBUG.
Still no crash. (I ran each binary under gdb 3 times, as when it crashes it
crashes more than once every 3 times I run it.) I tried building with -O2:
it crashes again. Now that it is built with the same options as etc/DEBUG,
except for -O2, is that more useful?

​I tried running Emacs with valgrind, but that just quickly bails out with
"memory exhausted".

>  If you are willing to try the debugging yourself, there's some advice
> >  in etc/DEBUG (search for "Debugging problems which happen in GC").
> >
> > ​I'll have a look.​
>
> Thanks.
>

​Sorry: having had a look, the reconstruction of Lisp data structures looks
like more than I have time for at present.


> >  Do I understand correctly that this worked for you with Emacs 24.5?
> >
> > ​Yes, the identical setup loads fine in 24.5. I've never seen this sort
> of crash before.​
>
> Does Emacs crash when restoring a desktop file written by Emacs 24.5,
> or only when it restores files written by Emacs 25?
>

​Both.

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 3986 bytes --]

bug#24640: Crashes in 25.1

[Eli Zaretskii]

> From: Reuben Thomas <rrt@sc3d.org>
> Date: Sun, 9 Oct 2016 21:21:01 +0100
> Cc: 24640@debbugs.gnu.org
> 
> ​I rebuilt with the options suggested in etc/DEBUG, and couldn't get it to crash.
> ​ I then tried building with -Og instead of -O0, as suggested in etc/DEBUG. Still no crash. (I ran each binary
> under gdb 3 times, as when it crashes it crashes more than once every 3 times I run it.) I tried building with
> -O2: it crashes again. Now that it is built with the same options as etc/DEBUG, except for -O2, is that more
> useful?

I'm not sure.  What compiler switches yo used, and what is your GCC
version?

>  > If you are willing to try the debugging yourself, there's some advice
>  > in etc/DEBUG (search for "Debugging problems which happen in GC").
>  >
>  > ​I'll have a look.​
> 
>  Thanks.
> 
> ​Sorry: having had a look, the reconstruction of Lisp data structures looks like more than I have time for at
> present.

Can you give me a shell login to your machine, and set it up so that
after a login I could connect to the GDB session with a crashed Emacs?
SSH is fine.

Thanks.

bug#24640: Crashes in 25.1

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 720 bytes --]

On 10 October 2016 at 07:15, Eli Zaretskii <eliz@gnu.org> wrote:

>
> I'm not sure.  What compiler switches yo used, and what is your GCC
> version?
>

​$ ./config.status --config
'--enable-checking=yes,glyphs' '--enable-check-lisp-object-type'
'CFLAGS=-O2 -g3'
'PKG_CONFIG_PATH=/home/rrt/.local/lib/x86_64-linux-gnu/pkgconfig:/home/rrt/.local/share/pkgconfig'
​$​
 gcc --version
gcc-5.real (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609
​

> Can you give me a shell login to your machine, and set it up so that
> after a login I could connect to the GDB session with a crashed Emacs?
> SSH is fine.
>

​Yes, no problem. I'll contact you privately about this.

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1701 bytes --]

bug#24640: Crashes in 25.1

[Eli Zaretskii]

> From: Reuben Thomas <rrt@sc3d.org>
> Date: Mon, 10 Oct 2016 17:12:36 +0100
> Cc: 24640@debbugs.gnu.org
> 
>  I'm not sure. What compiler switches yo used, and what is your GCC
>  version?
> 
> ​$ ./config.status --config
> '--enable-checking=yes,glyphs' '--enable-check-lisp-object-type' 'CFLAGS=-O2 -g3'
> 'PKG_CONFIG_PATH=/home/rrt/.local/lib/x86_64-linux-gnu/pkgconfig:/home/rrt/.local/share/pkgconfig'
> ​$​
> gcc --version
> gcc-5.real (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609

It would be better to use CFLAGS='-O2 -gdwarf-4 -g3'.

>  Can you give me a shell login to your machine, and set it up so that
>  after a login I could connect to the GDB session with a crashed Emacs?
>  SSH is fine.
> 
> ​Yes, no problem. I'll contact you privately about this.

Thanks.

bug#24640: Crashes in 25.1

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

On 10 October 2016 at 17:33, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Reuben Thomas <rrt@sc3d.org>
> > Date: Mon, 10 Oct 2016 17:12:36 +0100
> > Cc: 24640@debbugs.gnu.org
> >
> >  I'm not sure. What compiler switches yo used, and what is your GCC
> >  version?
> >
> > ​$ ./config.status --config
> > '--enable-checking=yes,glyphs' '--enable-check-lisp-object-type'
> 'CFLAGS=-O2 -g3'
> > 'PKG_CONFIG_PATH=/home/rrt/.local/lib/x86_64-linux-gnu/
> pkgconfig:/home/rrt/.local/share/pkgconfig'
> > ​$​
> > gcc --version
> > gcc-5.real (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609
>
> It would be better to use CFLAGS='-O2 -gdwarf-4 -g3'.
>

​Is that something that should be mentioned in etc/DEBUG, or is it specific
to the problems of debugging optimized code? (Or perhaps both!)

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1630 bytes --]

bug#24640: Crashes in 25.1

[Eli Zaretskii]

> From: Reuben Thomas <rrt@sc3d.org>
> Date: Mon, 10 Oct 2016 18:01:34 +0100
> Cc: 24640@debbugs.gnu.org
> 
>  It would be better to use CFLAGS='-O2 -gdwarf-4 -g3'.
> 
> ​Is that something that should be mentioned in etc/DEBUG

It is there already.

bug#24640: Crashes in 25.1

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

On 10 October 2016 at 18:05, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Reuben Thomas <rrt@sc3d.org>
> > Date: Mon, 10 Oct 2016 18:01:34 +0100
> > Cc: 24640@debbugs.gnu.org
> >
> >  It would be better to use CFLAGS='-O2 -gdwarf-4 -g3'.
> >
> > ​Is that something that should be mentioned in etc/DEBUG
>
> It is there already.
>

​Indeed, I hadn't read far enough.

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1095 bytes --]

bug#24640: Crashes in 25.1

[Eli Zaretskii]

Thanks, I've done some initial debugging.  The crash seems to be
related to the variable read_objects, defined and used by lread.c.  It
is an alist of objects read with the #n=object form.  One of its
members is a corrupted Lisp object, which causes the GC crash when
this object is examined.

read_objects is a global variable, so it could be that some code
invoked in the middle of reading one #n=object form clobbers it by
reading another.  However, I don't immediately see such forms in the
few of your many init files I looked in.  Do you have any idea where
this could come from?  One place they are abundant is in *.elc files,
so maybe some recursive load together with the timer-based lazy
desktop operation does that?  I don't really have a working hypothesis
for now.

I'm not an expert on X tricks -- is there any way you can trick Emacs
to start a GUI session when I invoke it via SSH?  Some trick with the
value of DISPLAY in the environment, perhaps?  I don't need to see
what Emacs displays, just run it live under GDB.  The problem that
causes the crash happens before the code I see in the backtrace --
that code just triggers GC.  So it would be beneficial to run Emacs
under GDB and try to see, for example, what code changes read_objects
and how (assuming it is not changed to a non-nil value too many
times).  Can this be arranged?

Thanks.

bug#24640: Crashes in 25.1

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 2251 bytes --]

On 11 October 2016 at 12:59, Eli Zaretskii <eliz@gnu.org> wrote:

> Thanks, I've done some initial debugging.  The crash seems to be
> related to the variable read_objects, defined and used by lread.c.  It
> is an alist of objects read with the #n=object form.  One of its
> members is a corrupted Lisp object, which causes the GC crash when
> this object is examined.
>

​Good stuff!


> read_objects is a global variable, so it could be that some code
> invoked in the middle of reading one #n=object form clobbers it by
> reading another.  However, I don't immediately see such forms in the
> few of your many init files I looked in.

​
Indeed, I'm not aware of having used such a form myself, nor can I find one
by grepping.


>   Do you have any idea where
> ​ ​
> this could come from?


​No, sorry.​


>   One place they are abundant is in *.elc files,
> so maybe some recursive load together with the timer-based lazy
> desktop operation does that?  I don't really have a working hypothesis
> for now.
>

Could it be loading the undo-tree undo history? The crash always seems to
happen when loading mit.tex. It tries to load the undo-tree history, fails
(because the file has been changed since the history was last saved), then
crashes. The undo-tree history is full of #n=object forms.

I can let you have the undo-tree history file if that might help you
identify the corrupted data.


> I'm not an expert on X tricks -- is there any way you can trick Emacs
> to start a GUI session when I invoke it via SSH?  Some trick with the
> value of DISPLAY in the environment, perhaps?  I don't need to see
> what Emacs displays, just run it live under GDB.  The problem that
> causes the crash happens before the code I see in the backtrace --
> that code just triggers GC.  So it would be beneficial to run Emacs
> under GDB and try to see, for example, what code changes read_objects
> and how (assuming it is not changed to a non-nil value too many
> times).  Can this be arranged?
>

​If you use "ssh -X", you can get an X connection and Emacs will start a
GUI session. That's the simplest thing I can think of; not really a trick
at all.​

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 3889 bytes --]

bug#24640: Crashes in 25.1

[Eli Zaretskii]

> From: Reuben Thomas <rrt@sc3d.org>
> Date: Tue, 11 Oct 2016 15:08:45 +0100
> Cc: 24640@debbugs.gnu.org
> 
>  read_objects is a global variable, so it could be that some code
>  invoked in the middle of reading one #n=object form clobbers it by
>  reading another. However, I don't immediately see such forms in the
>  few of your many init files I looked in.
> 
> ​Indeed, I'm not aware of having used such a form myself, nor can I find one by grepping.
> 
>  Do you have any idea where
>  ​ ​
>  this could come from?
> 
> ​No, sorry.​
> 
>  One place they are abundant is in *.elc files,
>  so maybe some recursive load together with the timer-based lazy
>  desktop operation does that? I don't really have a working hypothesis
>  for now.
> 
> Could it be loading the undo-tree undo history? The crash always seems to happen when loading mit.tex. It
> tries to load the undo-tree history, fails (because the file has been changed since the history was last saved),
> then crashes. The undo-tree history is full of #n=object forms.

Yes, that was also on my suspect list.

> I can let you have the undo-tree history file if that might help you identify the corrupted data.

Is it possible to disable this loading of undo-tree history?  If so,
can you disable it and see if Emacs no longer crashes?  If the crashes
stop when undo-tree history is not loaded, we will have to look
closely at what that loading does, because the problem is probably
there.  The internals of undo changed in Emacs 25.

>  I'm not an expert on X tricks -- is there any way you can trick Emacs
>  to start a GUI session when I invoke it via SSH? Some trick with the
>  value of DISPLAY in the environment, perhaps? I don't need to see
>  what Emacs displays, just run it live under GDB. The problem that
>  causes the crash happens before the code I see in the backtrace --
>  that code just triggers GC. So it would be beneficial to run Emacs
>  under GDB and try to see, for example, what code changes read_objects
>  and how (assuming it is not changed to a non-nil value too many
>  times). Can this be arranged?
> 
> ​If you use "ssh -X", you can get an X connection and Emacs will start a GUI session. That's the simplest thing
> I can think of; not really a trick at all.​

Yes, I know, but that requires me to have an X server here, which I
don't have, and prefer not to set up.  Is there some way of telling
Emacs to open its display on your local terminal instead?

bug#24640: Crashes in 25.1

[Eli Zaretskii]

> Date: Tue, 11 Oct 2016 17:53:33 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 24640@debbugs.gnu.org
> 
> > ​If you use "ssh -X", you can get an X connection and Emacs will start a GUI session. That's the simplest thing
> > I can think of; not really a trick at all.​
> 
> Yes, I know, but that requires me to have an X server here, which I
> don't have, and prefer not to set up.  Is there some way of telling
> Emacs to open its display on your local terminal instead?

Alternatively, maybe you could start Emacs yourself, stop it at the
beginning of 'main' (e.g. with the "start" command instead or "run"),
then let me connect to the terminal where GDB runs via 'screen' or
somesuch.  (I don't know the details, as I almost never use 'screen',
I just know that someone once provided such a possibility for me from
a remore login.)

TIA

bug#24640: Crashes in 25.1

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

On 11 October 2016 at 16:19, Eli Zaretskii <eliz@gnu.org> wrote:

>
> Alternatively, maybe you could start Emacs yourself, stop it at the
> beginning of 'main' (e.g. with the "start" command instead or "run"),
> then let me connect to the terminal where GDB runs via 'screen' or
> somesuch.  (I don't know the details, as I almost never use 'screen',
> I just know that someone once provided such a possibility for me from
> a remore login.)
>

I could do this too if you like.

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1234 bytes --]

bug#24640: Crashes in 25.1

[Eli Zaretskii]

> From: Reuben Thomas <rrt@sc3d.org>
> Date: Tue, 11 Oct 2016 16:42:21 +0100
> Cc: 24640@debbugs.gnu.org
> 
> On 11 October 2016 at 16:19, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>  Alternatively, maybe you could start Emacs yourself, stop it at the
>  beginning of 'main' (e.g. with the "start" command instead or "run"),
>  then let me connect to the terminal where GDB runs via 'screen' or
>  somesuch. (I don't know the details, as I almost never use 'screen',
>  I just know that someone once provided such a possibility for me from
>  a remore login.)
> 
> I could do this too if you like.

Let's see if the Xvfb method could be made to work.

Thanks.

bug#24640: Crashes in 25.1

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

On 11 October 2016 at 15:53, Eli Zaretskii <eliz@gnu.org> wrote:

>
> Is it possible to disable this loading of undo-tree history?  If so,
> can you disable it and see if Emacs no longer crashes?  If the crashes
> stop when undo-tree history is not loaded, we will have to look
> closely at what that loading does, because the problem is probably
> there.  The internals of undo changed in Emacs 25.
>

​Yes, the crashes appear to stop when I comment out (global-undo-tree-mode)
in vars.el.

Yes, I know, but that requires me to have an X server here, which I
> don't have, and prefer not to set up.  Is there some way of telling
> Emacs to open its display on your local terminal instead?
>

​$ Xvfb :2 # or some other number that doesn't cause an error
$ emacs -d :2​

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1704 bytes --]

bug#24640: Crashes in 25.1

[Eli Zaretskii]

> From: Reuben Thomas <rrt@sc3d.org>
> Date: Tue, 11 Oct 2016 16:41:17 +0100
> Cc: 24640@debbugs.gnu.org
> 
>  Is it possible to disable this loading of undo-tree history? If so,
>  can you disable it and see if Emacs no longer crashes? If the crashes
>  stop when undo-tree history is not loaded, we will have to look
>  closely at what that loading does, because the problem is probably
>  there. The internals of undo changed in Emacs 25.
> 
> ​Yes, the crashes appear to stop when I comment out (global-undo-tree-mode) in vars.el.

OK, so we have our prime suspect.  Can you tell where I can find the
exact version of undo-tree-mode you are using?

Phillip, could you please look into that package and see if you can
spot any potential problems with the Emacs 25 undo internals?  TIA.

bug#24640: Crashes in 25.1

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

On 11 October 2016 at 17:33, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Reuben Thomas <rrt@sc3d.org>
> > Date: Tue, 11 Oct 2016 16:41:17 +0100
> > Cc: 24640@debbugs.gnu.org
> >
> >  Is it possible to disable this loading of undo-tree history? If so,
> >  can you disable it and see if Emacs no longer crashes? If the crashes
> >  stop when undo-tree history is not loaded, we will have to look
> >  closely at what that loading does, because the problem is probably
> >  there. The internals of undo changed in Emacs 25.
> >
> > ​Yes, the crashes appear to stop when I comment out
> (global-undo-tree-mode) in vars.el.
>
> OK, so we have our prime suspect.  Can you tell where I can find the
> exact version of undo-tree-mode you are using?
>

;; Version: 0.6.6
;; Keywords: convenience, files, undo, redo, history, tree
;; URL: http://www.dr-qubit.org/emacs.php
;; Repository: http://www.dr-qubit.org/git/undo-tree.git

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1795 bytes --]

bug#24640: Crashes in 25.1

[Eli Zaretskii]

> Date: Tue, 11 Oct 2016 19:33:20 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 24640@debbugs.gnu.org
> 
> > ​Yes, the crashes appear to stop when I comment out (global-undo-tree-mode) in vars.el.
> 
> OK, so we have our prime suspect.  Can you tell where I can find the
> exact version of undo-tree-mode you are using?
> 
> Phillip, could you please look into that package and see if you can
> spot any potential problems with the Emacs 25 undo internals?  TIA.

Some functions in undo-tree refer to or manipulate Emacs undo
internals:

  undo-list-pop-changeset
  undo-list-transfer-to-tree
  undo-list-rebuild-from-tree
  undo-tree-pull-undo-in-region-branch
  undo-tree-pull-redo-in-region-branch
  undo-tree-adjust-elements-to-elt
  undo-tree-apply-deltas
  undo-tree-undo-1
  undo-tree-redo-1

Do they perhaps need some adjustments to Emacs 25's undo?

Another potential issue is the new undo timer we have in Emacs 25 (see
undo-auto--boundary-ensure-timer in simple.el).  One way of checking
whether this is related to the crashes is to modify that function to
use a much larger value for the 1st argument of run-at-time, say
10000, so that the undo timer never fires during the startup.  Reuben,
could you try that?

bug#24640: Crashes in 25.1

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 1691 bytes --]

On 12 October 2016 at 11:31, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Tue, 11 Oct 2016 19:33:20 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 24640@debbugs.gnu.org
> >
> > > ​Yes, the crashes appear to stop when I comment out
> (global-undo-tree-mode) in vars.el.
> >
> > OK, so we have our prime suspect.  Can you tell where I can find the
> > exact version of undo-tree-mode you are using?
> >
> > Phillip, could you please look into that package and see if you can
> > spot any potential problems with the Emacs 25 undo internals?  TIA.
>
> Some functions in undo-tree refer to or manipulate Emacs undo
> internals:
>
>   undo-list-pop-changeset
>   undo-list-transfer-to-tree
>   undo-list-rebuild-from-tree
>   undo-tree-pull-undo-in-region-branch
>   undo-tree-pull-redo-in-region-branch
>   undo-tree-adjust-elements-to-elt
>   undo-tree-apply-deltas
>   undo-tree-undo-1
>   undo-tree-redo-1
>
> Do they perhaps need some adjustments to Emacs 25's undo?
>

​And regardless of that, should it in principle be possible to crash Emacs
(other than by exhausting memory or CPU) from Lisp, except by calling
external code improperly?​

Another potential issue is the new undo timer we have in Emacs 25 (see
> undo-auto--boundary-ensure-timer in simple.el).  One way of checking
> whether this is related to the crashes is to modify that function to
> use a much larger value for the 1st argument of run-at-time, say
> 10000, so that the undo timer never fires during the startup.  Reuben,
> could you try that?
>

​Sure. I made that change in the sources and rebuilt, and it crashed "as
usual".

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 2744 bytes --]

bug#24640: Crashes in 25.1

[Eli Zaretskii]

> From: Reuben Thomas <rrt@sc3d.org>
> Date: Wed, 12 Oct 2016 11:57:26 +0100
> Cc: Phillip Lord <phillip.lord@russet.org.uk>, "Toby S. Cubitt" <tsc25@cantab.net>, 24640@debbugs.gnu.org
> 
> ​And regardless of that, should it in principle be possible to crash Emacs (other than by exhausting memory or
> CPU) from Lisp, except by calling external code improperly?​

No.  Otherwise I wouldn't be spending so much time on this ;-)

bug#24640: Crashes in 25.1

[Toby Cubitt]

On Wed, Oct 12, 2016 at 01:31:05PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 11 Oct 2016 19:33:20 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 24640@debbugs.gnu.org
> > 
> > > ​Yes, the crashes appear to stop when I comment out (global-undo-tree-mode) in vars.el.

You can also disable history loading without disabling
global-undo-tree-mode, by disabling undo-tree-auto-save-history. Might be
worth doing this more fine-grained check to confirm.

> > OK, so we have our prime suspect.  Can you tell where I can find the
> > exact version of undo-tree-mode you are using?
> > 
> > Phillip, could you please look into that package and see if you can
> > spot any potential problems with the Emacs 25 undo internals?  TIA.

>From the bug tracker discussion, it sounds like you're close to boiling
this down to some simple steps involving one undo-tree history file that
trigger the crash.

If you can send me the file and a list of steps to reproduce from
emacs -Q, I'd be happy to look into the undo-tree side of things.

> Some functions in undo-tree refer to or manipulate Emacs undo
> internals:
> 
>   undo-list-pop-changeset
>   undo-list-transfer-to-tree
>   undo-list-rebuild-from-tree
>   undo-tree-pull-undo-in-region-branch
>   undo-tree-pull-redo-in-region-branch
>   undo-tree-adjust-elements-to-elt
>   undo-tree-apply-deltas
>   undo-tree-undo-1
>   undo-tree-redo-1
> 
> Do they perhaps need some adjustments to Emacs 25's undo?

The only Emacs undo internal that undo-tree manipulates is the
buffer-undo-list variable. The only functions that do so are:

  undo-list-pop-changeset
  undo-list-transfer-to-tree
  undo-list-rebuild-from-tree

All the others either call one of these, or only touch buffer-undo-tree
which is a variable defined in the undo-tree package and which the Emacs
undo internals know nothing about.

Has the format of buffer-undo-list has changed at all? If so, then the
three above might need adjustment. If not, they should work as before.

The only other Emacs undo internals used by undo-tree are to call
primitive-undo and undo-boundary when undo/redoing.


> Another potential issue is the new undo timer we have in Emacs 25 (see
> undo-auto--boundary-ensure-timer in simple.el).  One way of checking
> whether this is related to the crashes is to modify that function to
> use a much larger value for the 1st argument of run-at-time, say
> 10000, so that the undo timer never fires during the startup.  Reuben,
> could you try that?

As far as I understand, the timer just adds undo boundaries to
buffer-undo-list in some of the open buffers. Undo-tree doesn't touch
buffer-undo-list (or do anything at all, in fact) until you call one of
its interactive commands.

Since the timer can't run whilst undo-tree lisp code is running, and
extra undo boundaries are no problem for undo-tree, I'd be surprised if
the new undo timer is the culprit.

Best,
Toby
-- 
Dr T. S. Cubitt
Royal Society University Research Fellow
Quantum Information Theory
Department of Computer Science
University College London

email: tsc25@cantab.net
web:   www.dr-qubit.org

bug#24640: Crashes in 25.1

[Eli Zaretskii]

> Date: Wed, 12 Oct 2016 14:50:20 +0100
> Cc: phillip.lord@russet.org.uk, rrt@sc3d.org, 24640@debbugs.gnu.org
> From: Toby Cubitt <tsc25@cantab.net>
> 
> On Wed, Oct 12, 2016 at 01:31:05PM +0300, Eli Zaretskii wrote:
> > > Date: Tue, 11 Oct 2016 19:33:20 +0300
> > > From: Eli Zaretskii <eliz@gnu.org>
> > > Cc: 24640@debbugs.gnu.org
> > > 
> > > > ​Yes, the crashes appear to stop when I comment out (global-undo-tree-mode) in vars.el.
> 
> You can also disable history loading without disabling
> global-undo-tree-mode, by disabling undo-tree-auto-save-history. Might be
> worth doing this more fine-grained check to confirm.

Thanks for chiming in.

> > > Phillip, could you please look into that package and see if you can
> > > spot any potential problems with the Emacs 25 undo internals?  TIA.
> 
> >From the bug tracker discussion, it sounds like you're close to boiling
> this down to some simple steps involving one undo-tree history file that
> trigger the crash.

They are only simple on Reuben's machine, as they involve a very large
setup of his Emacs sessions.  We don't have a reproducer for any other
machine.

What's more, the steps to reproduce may be simple (start Emacs and
wait for it to crash), finding the code that is the culprit for this
is anything but easy.  The crash is triggered by GC, and is due to an
invalid object being present in the value of read_objects, which holds
the object read by Emacs with the #n=object form.  The problem is that
the faulty object is deep in that list, so catching the code that puts
it there is not easy.  I'm still trying to devise a way for that, with
no real success so far.

> If you can send me the file and a list of steps to reproduce from
> emacs -Q, I'd be happy to look into the undo-tree side of things.

Thanks.  Maybe Reuben will be able to do that.

> > Some functions in undo-tree refer to or manipulate Emacs undo
> > internals:
> > 
> >   undo-list-pop-changeset
> >   undo-list-transfer-to-tree
> >   undo-list-rebuild-from-tree
> >   undo-tree-pull-undo-in-region-branch
> >   undo-tree-pull-redo-in-region-branch
> >   undo-tree-adjust-elements-to-elt
> >   undo-tree-apply-deltas
> >   undo-tree-undo-1
> >   undo-tree-redo-1
> > 
> > Do they perhaps need some adjustments to Emacs 25's undo?
> 
> The only Emacs undo internal that undo-tree manipulates is the
> buffer-undo-list variable. The only functions that do so are:
> 
>   undo-list-pop-changeset
>   undo-list-transfer-to-tree
>   undo-list-rebuild-from-tree
> 
> All the others either call one of these, or only touch buffer-undo-tree
> which is a variable defined in the undo-tree package and which the Emacs
> undo internals know nothing about.
> 
> Has the format of buffer-undo-list has changed at all? If so, then the
> three above might need adjustment. If not, they should work as before.
> 
> The only other Emacs undo internals used by undo-tree are to call
> primitive-undo and undo-boundary when undo/redoing.

I counted this last class among those listed above.

> > Another potential issue is the new undo timer we have in Emacs 25 (see
> > undo-auto--boundary-ensure-timer in simple.el).  One way of checking
> > whether this is related to the crashes is to modify that function to
> > use a much larger value for the 1st argument of run-at-time, say
> > 10000, so that the undo timer never fires during the startup.  Reuben,
> > could you try that?
> 
> As far as I understand, the timer just adds undo boundaries to
> buffer-undo-list in some of the open buffers. Undo-tree doesn't touch
> buffer-undo-list (or do anything at all, in fact) until you call one of
> its interactive commands.

Does restoring undo-tree history manipulates buffer-undo-list of any
buffers in any way?

> Since the timer can't run whilst undo-tree lisp code is running

It can run if during restoring the history, undo-tree calls sit-for,
or asks a question, or calls some other API that enters redisplay
and/or involves user input.

> I'd be surprised if the new undo timer is the culprit.

It could be a culprit, but evidently isn't, as Reuben already tried to
disable it.

Thanks.

bug#24640: Crashes in 25.1

[Toby Cubitt]

On Wed, Oct 12, 2016 at 05:44:55PM +0300, Eli Zaretskii wrote:
> What's more, the steps to reproduce may be simple (start Emacs and
> wait for it to crash), finding the code that is the culprit for this
> is anything but easy.  The crash is triggered by GC, and is due to an
> invalid object being present in the value of read_objects, which holds
> the object read by Emacs with the #n=object form.  The problem is that
> the faulty object is deep in that list, so catching the code that puts
> it there is not easy.  I'm still trying to devise a way for that, with
> no real success so far.

I understand. I can't help at all with the GC bug, unfortunately, as it's
well outside my Emacs knowledge.

I know what the buffer-undo-tree data structure looks like that gets
written and read from file, so if I can help at any point by picking
apart or simplifying that lisp structure, let me know.

> > > Some functions in undo-tree refer to or manipulate Emacs undo
> > > internals:
> > > 
> > >   undo-list-pop-changeset
> > >   undo-list-transfer-to-tree
> > >   undo-list-rebuild-from-tree
> > >   undo-tree-pull-undo-in-region-branch
> > >   undo-tree-pull-redo-in-region-branch
> > >   undo-tree-adjust-elements-to-elt
> > >   undo-tree-apply-deltas
> > >   undo-tree-undo-1
> > >   undo-tree-redo-1
> > > 
> > > Do they perhaps need some adjustments to Emacs 25's undo?
> > 
> > The only Emacs undo internal that undo-tree manipulates is the
> > buffer-undo-list variable. The only functions that do so are:
> > 
> >   undo-list-pop-changeset
> >   undo-list-transfer-to-tree
> >   undo-list-rebuild-from-tree
> > 
> > All the others either call one of these, or only touch buffer-undo-tree
> > which is a variable defined in the undo-tree package and which the Emacs
> > undo internals know nothing about.
> > 
> > Has the format of buffer-undo-list has changed at all? If so, then the
> > three above might need adjustment. If not, they should work as before.
> > 
> > The only other Emacs undo internals used by undo-tree are to call
> > primitive-undo and undo-boundary when undo/redoing.
> 
> I counted this last class among those listed above.

Indeed. I was attempting to explain which ones manipulate
buffer-undo-list "behind Emacs' back", and which ones just call out to
undo functions.

In case it helps, note that none of the above functions get called when
reloading history from file.

> > > Another potential issue is the new undo timer we have in Emacs 25 (see
> > > undo-auto--boundary-ensure-timer in simple.el).  One way of checking
> > > whether this is related to the crashes is to modify that function to
> > > use a much larger value for the 1st argument of run-at-time, say
> > > 10000, so that the undo timer never fires during the startup.  Reuben,
> > > could you try that?
> > 
> > As far as I understand, the timer just adds undo boundaries to
> > buffer-undo-list in some of the open buffers. Undo-tree doesn't touch
> > buffer-undo-list (or do anything at all, in fact) until you call one of
> > its interactive commands.
> 
> Does restoring undo-tree history manipulates buffer-undo-list of any
> buffers in any way?

No. It just reads a lisp structure from file into the buffer-undo-tree
variable.

> > Since the timer can't run whilst undo-tree lisp code is running
> 
> It can run if during restoring the history, undo-tree calls sit-for, or
> asks a question, or calls some other API that enters redisplay and/or
> involves user input.

During history loading it doesn't access buffer-undo-list at all, so it
shouldn't matter if the timer runs.

When undoing, everything that accesses or touches buffer-undo-list is
encapsulated in the three functions I listed. None of these call sit-for,
prompt for input, or display anything. As far as I understand it, they
shouldn't be able to trigger redisplay at all (caveat I'm no redisplay
expert - that's you!)

I don't think the undo timer can trigger elsewhere during undo-tree
undo. Even if it does somehow trigger outside those three functions, this
shouldn't break anything. Depending on when it triggers, undo-tree will
either pick up the extra undo boundary added to buffer-undo-list this
time around, or next time you undo.

> > I'd be surprised if the new undo timer is the culprit.
> 
> It could be a culprit, but evidently isn't, as Reuben already tried to
> disable it.

Indeed. But even if it's not to blame here, I still ought double-check
the above carefully to make sure the new undo timer doesn't interact with
undo-tree in some subtle way I've overlooked.

Cheers,
Toby
-- 
Dr T. S. Cubitt
Royal Society University Research Fellow
Quantum Information Theory
Department of Computer Science
University College London

email: tsc25@cantab.net
web:   www.dr-qubit.org

bug#24640: Crashes in 25.1

[Eli Zaretskii]

> Date: Wed, 12 Oct 2016 17:56:56 +0100
> Cc: phillip.lord@russet.org.uk, rrt@sc3d.org, 24640@debbugs.gnu.org
> From: Toby Cubitt <tsc25@cantab.net>
> 
> > Does restoring undo-tree history manipulates buffer-undo-list of any
> > buffers in any way?
> 
> No. It just reads a lisp structure from file into the buffer-undo-tree
> variable.

In that case, changes in Emacs undo internals are probably off the
hook.  Hmm... which leaves us with what other suspects?

> > > Since the timer can't run whilst undo-tree lisp code is running
> > 
> > It can run if during restoring the history, undo-tree calls sit-for, or
> > asks a question, or calls some other API that enters redisplay and/or
> > involves user input.
> 
> During history loading it doesn't access buffer-undo-list at all, so it
> shouldn't matter if the timer runs.
> 
> When undoing, everything that accesses or touches buffer-undo-list is
> encapsulated in the three functions I listed. None of these call sit-for,
> prompt for input, or display anything. As far as I understand it, they
> shouldn't be able to trigger redisplay at all (caveat I'm no redisplay
> expert - that's you!)

Well, one place where redisplay could be triggered is those messages
about failure to load history, like this one (which actually happens
during restoring Emacs sessions from Reuben's desktop file):

  Error reading undo-tree history from "/home/user/.emacs.d/undo-tree/.!home!user!Foo!Bar!baz!doc!yyy.tex.~undo-tree~"

(I obfuscated a few directory names here to protect Reuben's privacy.)

Each such message enters redisplay.

But again, the undo timer is not the culprit, so this is just for
completeness.

> I don't think the undo timer can trigger elsewhere during undo-tree
> undo. Even if it does somehow trigger outside those three functions, this
> shouldn't break anything. Depending on when it triggers, undo-tree will
> either pick up the extra undo boundary added to buffer-undo-list this
> time around, or next time you undo.

I originally asked that question because Reuben's setup arranges for
restoring the session lazily, which means buffers are restored from
their files by functions that run off the idle timer.  So I thought
about two timers stepping on each other's toes.  Again, that proved to
be a dead end, at least for now.

> Indeed. But even if it's not to blame here, I still ought double-check
> the above carefully to make sure the new undo timer doesn't interact with
> undo-tree in some subtle way I've overlooked.

That's prudent, of course.

Thanks.

bug#24640: Crashes in 25.1

[Toby Cubitt]

On Wed, Oct 12, 2016 at 08:28:47PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 12 Oct 2016 17:56:56 +0100
> > Cc: phillip.lord@russet.org.uk, rrt@sc3d.org, 24640@debbugs.gnu.org
> > From: Toby Cubitt <tsc25@cantab.net>
> > 
> > > Does restoring undo-tree history manipulates buffer-undo-list of any
> > > buffers in any way?
> > 
> > No. It just reads a lisp structure from file into the buffer-undo-tree
> > variable.
> 
> In that case, changes in Emacs undo internals are probably off the
> hook.  Hmm... which leaves us with what other suspects?

Does loading Reuben's history file using undo-tree-load-history starting
from emacs -Q trigger the crash? From the discussion, I'm guessing not...

> Well, one place where redisplay could be triggered is those messages
> about failure to load history, like this one (which actually happens
> during restoring Emacs sessions from Reuben's desktop file):
> 
>   Error reading undo-tree history from "/home/user/.emacs.d/undo-tree/.!home!user!Foo!Bar!baz!doc!yyy.tex.~undo-tree~"
> 
> (I obfuscated a few directory names here to protect Reuben's privacy.)

That's odd. That particular error message can only be triggered if one of
the two (read (current-buffer)) calls fails. It means the undo history
file exists, but `read' could not parse the contents into a lisp
expression (or errored for some other reason).

This shouldn't be possible. Undo-tree uses `prin1` to write one hash and
one complicated lisp structure to the file when it saves history. The
lisp structure does have a read syntax. Unless the history file has been
modified outside of undo-tree, it should always be able to read these
back in.

Normal situations, like failing to find an undo history file or detecting
that the file has changed since the history was written, trigger
different error messages.

Maybe this is a red herring, since failing to read a lisp expression
shouldn't crash Emacs anyway. But it's odd to me that this message is
triggered at all...

T.
-- 
Dr T. S. Cubitt
Royal Society University Research Fellow
Quantum Information Theory
Department of Computer Science
University College London

email: tsc25@cantab.net
web:   www.dr-qubit.org

bug#24640: Crashes in 25.1

[Eli Zaretskii]

> Date: Wed, 12 Oct 2016 19:07:26 +0100
> Cc: phillip.lord@russet.org.uk, rrt@sc3d.org, 24640@debbugs.gnu.org
> From: Toby Cubitt <tsc25@cantab.net>
> 
> Does loading Reuben's history file using undo-tree-load-history starting
> from emacs -Q trigger the crash? From the discussion, I'm guessing not...

Reuben said no.  And I see it in my debugging on his machine: the bug
is triggered in a very specific place for a single file, although
several other files have their undo-tree history read and restored.

> > Well, one place where redisplay could be triggered is those messages
> > about failure to load history, like this one (which actually happens
> > during restoring Emacs sessions from Reuben's desktop file):
> > 
> >   Error reading undo-tree history from "/home/user/.emacs.d/undo-tree/.!home!user!Foo!Bar!baz!doc!yyy.tex.~undo-tree~"
> > 
> > (I obfuscated a few directory names here to protect Reuben's privacy.)
> 
> That's odd. That particular error message can only be triggered if one of
> the two (read (current-buffer)) calls fails. It means the undo history
> file exists, but `read' could not parse the contents into a lisp
> expression (or errored for some other reason).
> 
> This shouldn't be possible. Undo-tree uses `prin1` to write one hash and
> one complicated lisp structure to the file when it saves history. The
> lisp structure does have a read syntax. Unless the history file has been
> modified outside of undo-tree, it should always be able to read these
> back in.
> 
> Normal situations, like failing to find an undo history file or detecting
> that the file has changed since the history was written, trigger
> different error messages.
> 
> Maybe this is a red herring, since failing to read a lisp expression
> shouldn't crash Emacs anyway. But it's odd to me that this message is
> triggered at all...

Your surprise is IMO a reason good enough to ask Reuben to send you
the undo-tree history file for analysis.  Who knows, it might even be
the clue we are looking for.  (I agree that the error alone should
not, and most probably is not, the cause of the crash.)

In the *Messages* buffer at the point of the crash, I see error
messages like above for 2 more files (but only one of the 3
immediately precedes a crash in GC, although GC happens after the
previous errors as well).

bug#24640: Crashes in 25.1

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]

On 12 October 2016 at 20:15, Eli Zaretskii <eliz@gnu.org> wrote:

>
> Your surprise is IMO a reason good enough to ask Reuben to send you
> the undo-tree history file for analysis.  Who knows, it might even be
> the clue we are looking for.  (I agree that the error alone should
> not, and most probably is not, the cause of the crash.)
>

​Toby, I'm happy to send you this file if you like.​

​Apologies, I'm having trouble following all the ramifications of Eli's
energetic debugging effort; is there any other action you (Toby) would like
me to take?

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1293 bytes --]

bug#24640: Crashes in 25.1

[Eli Zaretskii]

> From: Reuben Thomas <rrt@sc3d.org>
> Date: Wed, 12 Oct 2016 21:45:14 +0100
> Cc: Toby Cubitt <tsc25@cantab.net>, Phillip Lord <phillip.lord@russet.org.uk>, 24640@debbugs.gnu.org
> 
> On 12 October 2016 at 20:15, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>  Your surprise is IMO a reason good enough to ask Reuben to send you
>  the undo-tree history file for analysis. Who knows, it might even be
>  the clue we are looking for. (I agree that the error alone should
>  not, and most probably is not, the cause of the crash.)
> 
> ​Toby, I'm happy to send you this file if you like.​
> 
> ​Apologies, I'm having trouble following all the ramifications of Eli's energetic debugging effort; is there any
> other action you (Toby) would like me to take?

This bug is now fixed on the emacs-25 branch.  It was caused by a
change 2 years ago that placed a stack-allocated cons cell in a
staticpro'd list that is a value of a global variable, which isn't
cleared when that stack slot goes out of scope.

Many thanks to Reuben for letting me (ab)use his system and his time
in order to find and fix this bug.