* bug#66743: 30.0.50; Crash when dumping reftex
@ 2023-10-25 9:46 Ihor Radchenko
2023-10-25 12:46 ` Eli Zaretskii
0 siblings, 1 reply; 32+ messages in thread
From: Ihor Radchenko @ 2023-10-25 9:46 UTC (permalink / raw)
To: 66743
Steps to reproduce:
emacs -Q --batch -l dump.el
with dump.el
(dolist (feature
'(reftex))
(require feature))
(dump-emacs-portable "/tmp/emacs-dumped.dmp")
backtrace:
> gdb ./src/emacs
GNU gdb (Gentoo 13.2 vanilla) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./src/emacs...
(gdb) r -Q --batch -l ~/Downloads/dump.el
Starting program: /home/yantar92/Git/emacs/src/emacs -Q --batch -l ~/Downloads/dump.el
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Dumping fingerprint: 5acd811165d6d182fbd73abb4c6c15d260fb955edbc8546ae480755ae797ea08
Fatal error 6: Aborted
Backtrace:
/home/yantar92/Git/emacs/src/emacs(+0x276d4a)[0x5555557cad4a]
/home/yantar92/Git/emacs/src/emacs(+0x2371f6)[0x55555578b1f6]
/home/yantar92/Git/emacs/src/emacs(+0x276dde)[0x5555557cadde]
/home/yantar92/Git/emacs/src/emacs(+0x3023f7)[0x5555558563f7]
/home/yantar92/Git/emacs/src/emacs(+0x302a27)[0x555555856a27]
/home/yantar92/Git/emacs/src/emacs(+0x302f5c)[0x555555856f5c]
/home/yantar92/Git/emacs/src/emacs(+0x305ccd)[0x555555859ccd]
/home/yantar92/Git/emacs/src/emacs(+0x3065ce)[0x55555585a5ce]
/home/yantar92/Git/emacs/src/emacs(+0x33a54d)[0x55555588e54d]
/home/yantar92/Git/emacs/src/emacs(+0x385837)[0x5555558d9837]
/home/yantar92/Git/emacs/src/emacs(+0x3860f7)[0x5555558da0f7]
/home/yantar92/Git/emacs/src/emacs(+0x386443)[0x5555558da443]
/home/yantar92/Git/emacs/src/emacs(+0x33c27b)[0x55555589027b]
/home/yantar92/Git/emacs/src/emacs(+0x3a3ed4)[0x5555558f7ed4]
/home/yantar92/Git/emacs/src/emacs(+0x33c58c)[0x55555589058c]
/home/yantar92/Git/emacs/src/emacs(+0x33ca38)[0x555555890a38]
/home/yantar92/Git/emacs/src/emacs(+0x33bc04)[0x55555588fc04]
/home/yantar92/Git/emacs/src/emacs(+0x33bf18)[0x55555588ff18]
/home/yantar92/Git/emacs/src/emacs(+0x37f243)[0x5555558d3243]
/home/yantar92/Git/emacs/src/emacs(+0x383841)[0x5555558d7841]
/home/yantar92/Git/emacs/src/emacs(+0x33c27b)[0x55555589027b]
/home/yantar92/Git/emacs/src/emacs(+0x3a3ed4)[0x5555558f7ed4]
/home/yantar92/Git/emacs/src/emacs(+0x33c58c)[0x55555589058c]
/home/yantar92/Git/emacs/src/emacs(+0x33ca38)[0x555555890a38]
/home/yantar92/Git/emacs/src/emacs(+0x33c729)[0x555555890729]
/home/yantar92/Git/emacs/src/emacs(+0x33a739)[0x55555588e739]
/home/yantar92/Git/emacs/src/emacs(+0x339a5f)[0x55555588da5f]
/home/yantar92/Git/emacs/src/emacs(+0x24042c)[0x55555579442c]
/home/yantar92/Git/emacs/src/emacs(+0x3370fd)[0x55555588b0fd]
/home/yantar92/Git/emacs/src/emacs(+0x24047d)[0x55555579447d]
/home/yantar92/Git/emacs/src/emacs(+0x3361d3)[0x55555588a1d3]
/home/yantar92/Git/emacs/src/emacs(+0x240342)[0x555555794342]
/home/yantar92/Git/emacs/src/emacs(+0x23f68d)[0x55555579368d]
/home/yantar92/Git/emacs/src/emacs(+0x23f8b9)[0x5555557938b9]
/home/yantar92/Git/emacs/src/emacs(+0x23a813)[0x55555578e813]
/lib64/libc.so.6(+0x23eea)[0x7ffff586feea]
/lib64/libc.so.6(__libc_start_main+0x85)[0x7ffff586ffa5]
/home/yantar92/Git/emacs/src/emacs(+0x49eb1)[0x55555559deb1]
Program received signal SIGABRT, Aborted.
0x00007ffff58d3eac in ?? () from /lib64/libc.so.6
(gdb) bt full
#0 0x00007ffff58d3eac in () at /lib64/libc.so.6
#1 0x00007ffff58855c2 in raise () at /lib64/libc.so.6
#2 0x000055555578b242 in terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:484
#3 0x00005555557cadde in emacs_abort () at sysdep.c:2391
#4 0x00005555558563f7 in dump_buffer (ctx=0x7fffffffbeb0, in_buffer=0x7ffff1e62708) at pdumper.c:2866
munged_buffer = {header = {size = 4611686018645684299}, name_ = {i = 0x7ffff22df5e4}, filename_ = {i = 0x0}, directory_ = {i = 0x5555561c1d44}, backed_up_ = {i = 0x0}, save_length_ = {i = 0x2}, auto_save_file_name_ = {i = 0x0}, read_only_ = {i = 0x0}, mark_ = {i = 0x7ffff22df5b5}, local_var_alist_ = {i = 0x7ffff2dd5cb3}, major_mode_ = {i = 0x2aaa9bdea3c0}, local_minor_modes_ = {i = 0x0}, mode_name_ = {i = 0x7ffff2263844}, mode_line_format_ = {i = 0x7ffff1ef8b23}, header_line_format_ = {i = 0x0}, tab_line_format_ = {i = 0x0}, keymap_ = {i = 0x7ffff2263b9b}, abbrev_table_ = {i = 0x7ffff1eae275}, syntax_table_ = {i = 0x7ffff22638f5}, category_table_ = {i = 0x7ffff1ef69f5}, case_fold_search_ = {i = 0x30}, tab_width_ = {i = 0x22}, fill_column_ = {i = 0x11a}, left_margin_ = {i = 0x2}, auto_fill_function_ = {i = 0x0}, downcase_table_ = {i = 0x7ffff1ef6575}, upcase_table_ = {i = 0x7ffff1ef6335}, case_canon_table_ = {i = 0x7ffff2208a5d}, case_eqv_table_ = {i = 0x7ffff1ef67b5}, truncate_lines_ = {i = 0x0}, word_wrap_ = {i = 0x0}, ctl_arrow_ = {i = 0x30}, bidi_display_reordering_ = {i = 0x30}, bidi_paragraph_direction_ = {i = 0xab00}, bidi_paragraph_separate_re_ = {i = 0x0}, bidi_paragraph_start_re_ = {i = 0x0}, selective_display_ = {i = 0x0}, selective_display_ellipses_ = {i = 0x30}, overwrite_mode_ = {i = 0x0}, abbrev_mode_ = {i = 0x0}, display_table_ = {i = 0x0}, mark_active_ = {i = 0x0}, enable_multibyte_characters_ = {i = 0x30}, buffer_file_coding_system_ = {i = 0x11a90}, file_format_ = {i = 0x0}, auto_save_file_format_ = {i = 0x30}, cache_long_scans_ = {i = 0x30}, width_table_ = {i = 0x0}, pt_marker_ = {i = 0x0}, begv_marker_ = {i = 0x0}, zv_marker_ = {i = 0x0}, point_before_scroll_ = {i = 0x0}, file_truename_ = {i = 0x0}, invisibility_spec_ = {i = 0x30}, last_selected_window_ = {i = 0x0}, display_count_ = {i = 0x2}, left_margin_cols_ = {i = 0x2}, right_margin_cols_ = {i = 0x2}, left_fringe_width_ = {i = 0x0}, right_fringe_width_ = {i = 0x0}, fringes_outside_margins_ = {i = 0x0}, scroll_bar_width_ = {i = 0x0}, scroll_bar_height_ = {i = 0x0}, vertical_scroll_bar_type_ = {i = 0x30}, horizontal_scroll_bar_type_ = {i = 0x30}, indicate_empty_lines_ = {i = 0x0}, indicate_buffer_boundaries_ = {i = 0x0}, fringe_indicator_alist_ = {i = 0x7ffff1ef5db3}, fringe_cursor_alist_ = {i = 0x7ffff1e62b83}, display_time_ = {i = 0x7ffff2df0083}, scroll_up_aggressively_ = {i = 0x0}, scroll_down_aggressively_ = {i = 0x0}, cursor_type_ = {i = 0x30}, extra_line_spacing_ = {i = 0x0}, text_conversion_style_ = {i = 0x30}, cursor_in_non_selected_windows_ = {i = 0x30}, own_text = {beg = 0x7ffff2646800 "", gpt = 1, z = 1, gpt_byte = 1, z_byte = 1, gap_size = 20, modiff = 1, chars_modiff = 1, save_modiff = 1, overlay_modiff = 9, compact = 1, beg_unchanged = 0, end_unchanged = 0, unchanged_modified = 1, overlay_unchanged_modified = 1, intervals = 0x0, markers = 0x5555561e9c88, inhibit_shrinking = false, redisplay = true}, text = 0x7ffff1e62968, pt = 1, pt_byte = 1, begv = 1, begv_byte = 1, zv = 1, zv_byte = 1, base_buffer = 0x0, indirections = 0, window_count = 0, local_flags = '\000' <repeats 14 times>, "\001\000\001\000\000\000\001", '\000' <repeats 22 times>, "\001\000\000\000\000\000", modtime = {tv_sec = 0, tv_nsec = -2}, modtime_size = -1, auto_save_modified = 0, display_error_modiff = 0, auto_save_failure_time = 0, last_window_start = -1, newline_cache = 0x0, width_run_cache = 0x0, bidi_paragraph_cache = 0x0, prevent_redisplay_optimizations_p = true, clip_changed = false, inhibit_buffer_hooks = false, long_line_optimizations_p = false, overlays = 0x55555610c2a0, undo_list_ = {i = 0x0}}
buffer = 0x7fffffffb990
base_offset = 59144
_in_hdr = 0x7fffffffb990
out = 0x7fffffffb570
offset = 0
#5 0x0000555555856a27 in dump_vectorlike (ctx=0x7fffffffbeb0, lv=..., offset=-1) at pdumper.c:3031
v = 0x7ffff1e62708
#6 0x0000555555856f5c in dump_object (ctx=0x7fffffffbeb0, object=...) at pdumper.c:3173
offset = -1
cold = false
obj_in_emacs = 0x0
#7 0x0000555555859ccd in dump_drain_normal_queue (ctx=0x7fffffffbeb0) at pdumper.c:4030
--Type <RET> for more, q to quit, c to continue without paging--c
#8 0x000055555585a5ce in Fdump_emacs_portable (filename=..., track_referrers=...) at pdumper.c:4226
count = {bytes = 1120}
symbol = {i = 0x2aaa9bfdaac0}
ctx_buf = {header = {magic = "!UMPEDGNUEMACS\000", fingerprint = "Ź\021e\326т\373\327:\273Ll\025\322`\373\225^\333\310Tj\344\200uZ\347\227\352\b", dump_relocs = {{offset = 0, nr_entries = 0}, {offset = 0, nr_entries = 0}, {offset = 0, nr_entries = 0}}, object_starts = {offset = 0, nr_entries = 0}, emacs_relocs = {offset = 0, nr_entries = 0}, discardable_start = 0, cold_start = 0, hash_list = 0}, buf = 0x7ffff0dfe010, buf_size = 8388608, max_offset = 0, old_purify_flag = {i = 0x0}, old_post_gc_hook = {i = 0x0}, old_process_environment = {i = 0x7ffff2df0593}, fd = 4, dump_filename = {i = 0x5555562387c4}, offset = 59144, obj_offset = 59144, flags = {dump_object_contents = true, record_object_starts = true, pack_objects = false, assert_already_seen = false, defer_hash_tables = true, defer_symbols = false, defer_cold_objects = true, defer_copied_objects = true}, end_heap = 0, objects_dumped = {i = 0x55555616b14d}, referrers = {i = 0x0}, current_referrer = {i = 0x0}, have_current_referrer = true, dump_queue = {zero_weight_objects = {head = {i = 0x7ffff2dbea43}, tail = {i = 0x7ffff2df7b73}, length = 1949}, one_weight_normal_objects = {head = {i = 0x7ffff2dac193}, tail = {i = 0x7ffff2dac193}, length = 1}, one_weight_strong_objects = {head = {i = 0x7ffff2dac103}, tail = {i = 0x7ffff2dab993}, length = 18}, fancy_weight_objects = {head = {i = 0x0}, tail = {i = 0x0}, length = 0}, link_weights = {i = 0x555556173c5d}, sequence_numbers = {i = 0x5555561b92cd}, next_sequence_number = 1961}, deferred_hash_tables = {i = 0x0}, deferred_symbols = {i = 0x0}, fixups = {i = 0x7ffff2dac1f3}, staticpro_table = {i = 0x5555561deb75}, symbol_aux = {i = 0x0}, copied_queue = {i = 0x0}, cold_queue = {i = 0x7ffff2dac143}, dump_relocs = {{i = 0x0}, {i = 0x0}, {i = 0x0}}, object_starts = {i = 0x0}, emacs_relocs = {i = 0x7ffff2dab943}, bignum_data = {i = 0x5555561b5335}, hash_tables = {i = 0x0}, number_hot_relocations = 0, number_discardable_relocations = 0}
ctx = 0x7fffffffbeb0
header_start = 0
header_end = 100
hot_start = 100
hot_end = 32767
discardable_end = -1679013824
emacs_reloc_merger = 0x0
number_hot_relocations = 10922
number_discardable_relocations = 0
cold_end = 0
header_bytes = 0
hot_bytes = 0
discardable_bytes = 1443641760
cold_bytes = 21845
#9 0x000055555588e54d in eval_sub (form=...) at eval.c:2518
i = 2
maxargs = 2
args_left = {i = 0x0}
numargs = 1
original_fun = {i = 0x2aaa9bec4840}
original_args = {i = 0x7ffff2dc5ce3}
count = {bytes = 1088}
fun = {i = 0x555556031365 <Sdump_emacs_portable+5>}
val = {i = 0x7fffffffc100}
funcar = {i = 0x555555885fcd <specpdl_ref_to_ptr+36>}
argvals = {{i = 0x5555562387c4}, {i = 0x0}, {i = 0x7fffffffc1a0}, {i = 0x5555558d31c9 <call2+76>}, {i = 0x0}, {i = 0x30}, {i = 0x7ffff2dc5cd3}, {i = 0x2aaa9c042850}}
#10 0x00005555558d9837 in readevalloop_eager_expand_eval (val=..., macroexpand=...) at lread.c:2411
#11 0x00005555558da0f7 in readevalloop (readcharfun=..., infile0=0x0, sourcename=..., printflag=false, unibyte=..., readfun=..., start=..., end=...)
at lread.c:2595
count1 = {bytes = 1088}
c = 40
val = {i = 0x7ffff2dc5cd3}
count = {bytes = 928}
b = 0x5555561e96d8
continue_reading_p = true
lex_bound = {i = 0x0}
whole_buffer = true
first_sexp = false
macroexpand = {i = 0x2aaa9c042850}
#12 0x00005555558da443 in Feval_buffer (buffer=..., printflag=..., filename=..., unibyte=..., do_allow_print=...) at lread.c:2668
count = {bytes = 800}
tem = {i = 0x0}
buf = {i = 0x5555561e96dd}
#13 0x000055555589027b in funcall_subr (subr=0x555556037d60 <Seval_buffer>, numargs=5, args=0x7ffff15ff290) at eval.c:3059
argbuf = {{i = 0x7fffffffc3a0}, {i = 0x300}, {i = 0x7fffffffc3a0}, {i = 0x11558f643a}, {i = 0x555556037d65 <Seval_buffer+5>}, {i = 0x7fffffffc3c0}, {i = 0x5555558f6086 <SUBRP+29>}, {i = 0x555556037d65 <Seval_buffer+5>}}
a = 0x7ffff15ff290
fun = {i = 0x0}
#14 0x00005555558f7ed4 in exec_byte_code (fun=..., args_template=257, nargs=1, args=0x7ffff15ff298) at bytecode.c:815
call_nargs = 5
call_fun = {i = 0x555556037d65 <Seval_buffer+5>}
count1 = {bytes = 768}
template = {i = 0x406}
val = {i = 0x0}
call_args = 0x7ffff15ff290
original_fun = {i = 0x2aaa9be618b8}
bytecode = {i = 0x7ffff1e8c1ec}
op = 5
type = (CONDITION_CASE | CATCHER_ALL | unknown: 0x7ffc)
targets = {0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc89e <exec_byte_code+23248>, 0x5555558fc8a0 <exec_byte_code+23250>, 0x5555558fc8a2 <exec_byte_code+23252>, 0x5555558fc8a4 <exec_byte_code+23254>, 0x5555558fc8a4 <exec_byte_code+23254>, 0x5555558fc921 <exec_byte_code+23379>, 0x5555558fc9b0 <exec_byte_code+23522>, 0x5555558f737a <exec_byte_code+1452>, 0x5555558f737c <exec_byte_code+1454>, 0x5555558f737e <exec_byte_code+1456>, 0x5555558f7380 <exec_byte_code+1458>, 0x5555558f7382 <exec_byte_code+1460>, 0x5555558f7382 <exec_byte_code+1460>, 0x5555558f738b <exec_byte_code+1469>, 0x5555558f7337 <exec_byte_code+1385>, 0x5555558f78e8 <exec_byte_code+2842>, 0x5555558f78ea <exec_byte_code+2844>, 0x5555558f78ec <exec_byte_code+2846>, 0x5555558f78ee <exec_byte_code+2848>, 0x5555558f78f0 <exec_byte_code+2850>, 0x5555558f78f0 <exec_byte_code+2850>, 0x5555558f793a <exec_byte_code+2924>, 0x5555558f78f9 <exec_byte_code+2859>, 0x5555558f7b8b <exec_byte_code+3517>, 0x5555558f7b8d <exec_byte_code+3519>, 0x5555558f7b8f <exec_byte_code+3521>, 0x5555558f7b91 <exec_byte_code+3523>, 0x5555558f7b93 <exec_byte_code+3525>, 0x5555558f7b93 <exec_byte_code+3525>, 0x5555558f7b2a <exec_byte_code+3420>, 0x5555558f7b4a <exec_byte_code+3452>, 0x5555558f7c77 <exec_byte_code+3753>, 0x5555558f7c79 <exec_byte_code+3755>, 0x5555558f7c7b <exec_byte_code+3757>, 0x5555558f7c7d <exec_byte_code+3759>, 0x5555558f7c7f <exec_byte_code+3761>, 0x5555558f7c7f <exec_byte_code+3761>, 0x5555558f7c16 <exec_byte_code+3656>, 0x5555558f7c36 <exec_byte_code+3688>, 0x5555558f802c <exec_byte_code+4702>, 0x5555558f802e <exec_byte_code+4704>, 0x5555558f8030 <exec_byte_code+4706>, 0x5555558f8032 <exec_byte_code+4708>, 0x5555558f8034 <exec_byte_code+4710>, 0x5555558f8034 <exec_byte_code+4710>, 0x5555558f7fcb <exec_byte_code+4605>, 0x5555558f7feb <exec_byte_code+4637>, 0x5555558f8a14 <exec_byte_code+7238>, 0x5555558f8831 <exec_byte_code+6755>, 0x5555558f8825 <exec_byte_code+6743>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558f8cc5 <exec_byte_code+7927>, 0x5555558f8ee2 <exec_byte_code+8468>, 0x5555558f8f66 <exec_byte_code+8600>, 0x5555558f8fe8 <exec_byte_code+8730>, 0x5555558f906c <exec_byte_code+8862>, 0x5555558f76a9 <exec_byte_code+2267>, 0x5555558f7753 <exec_byte_code+2437>, 0x5555558f910a <exec_byte_code+9020>, 0x5555558f7598 <exec_byte_code+1994>, 0x5555558f77d6 <exec_byte_code+2568>, 0x5555558f9194 <exec_byte_code+9158>, 0x5555558f9217 <exec_byte_code+9289>, 0x5555558f9274 <exec_byte_code+9382>, 0x5555558f92f7 <exec_byte_code+9513>, 0x5555558f937b <exec_byte_code+9645>, 0x5555558f94ac <exec_byte_code+9950>, 0x5555558f9509 <exec_byte_code+10043>, 0x5555558f96d0 <exec_byte_code+10498>, 0x5555558f98c4 <exec_byte_code+10998>, 0x5555558f9921 <exec_byte_code+11091>, 0x5555558f997e <exec_byte_code+11184>, 0x5555558f9a01 <exec_byte_code+11315>, 0x5555558f9a84 <exec_byte_code+11446>, 0x5555558f9b07 <exec_byte_code+11577>, 0x5555558f9bad <exec_byte_code+11743>, 0x5555558f9c14 <exec_byte_code+11846>, 0x5555558f9c7b <exec_byte_code+11949>, 0x5555558f9d84 <exec_byte_code+12214>, 0x5555558f9ea3 <exec_byte_code+12501>, 0x5555558f9fc2 <exec_byte_code+12788>, 0x5555558fa0c2 <exec_byte_code+13044>, 0x5555558fa1d2 <exec_byte_code+13316>, 0x5555558fa2e2 <exec_byte_code+13588>, 0x5555558fa3f2 <exec_byte_code+13860>, 0x5555558fa502 <exec_byte_code+14132>, 0x5555558fa68d <exec_byte_code+14527>, 0x5555558fa7ad <exec_byte_code+14815>, 0x5555558fa944 <exec_byte_code+15222>, 0x5555558faa2b <exec_byte_code+15453>, 0x5555558fab12 <exec_byte_code+15684>, 0x5555558fb01d <exec_byte_code+16975>, 0x5555558f865a <exec_byte_code+6284>, 0x5555558fb08d <exec_byte_code+17087>, 0x5555558fb0ea <exec_byte_code+17180>, 0x5555558fb1eb <exec_byte_code+17437>, 0x5555558fb25b <exec_byte_code+17549>, 0x5555558fb2cb <exec_byte_code+17661>, 0x5555558fb328 <exec_byte_code+17754>, 0x5555558fb380 <exec_byte_code+17842>, 0x5555558fb3d8 <exec_byte_code+17930>, 0x5555558fb438 <exec_byte_code+18026>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fb4a5 <exec_byte_code+18135>, 0x5555558fb4fd <exec_byte_code+18223>, 0x5555558fb555 <exec_byte_code+18311>, 0x5555558fb5ad <exec_byte_code+18399>, 0x5555558fb605 <exec_byte_code+18487>, 0x5555558fb65d <exec_byte_code+18575>, 0x5555558f865a <exec_byte_code+6284>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fb6ba <exec_byte_code+18668>, 0x5555558fb71f <exec_byte_code+18769>, 0x5555558fb77c <exec_byte_code+18862>, 0x5555558fb7d9 <exec_byte_code+18955>, 0x5555558fb85c <exec_byte_code+19086>, 0x5555558fb8df <exec_byte_code+19217>, 0x5555558fb93c <exec_byte_code+19310>, 0x5555558fb999 <exec_byte_code+19403>, 0x5555558fba1c <exec_byte_code+19534>, 0x5555558fba9f <exec_byte_code+19665>, 0x5555558fbb22 <exec_byte_code+19796>, 0x5555558fbb7a <exec_byte_code+19884>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558f8571 <exec_byte_code+6051>, 0x5555558f80ac <exec_byte_code+4830>, 0x5555558f74e2 <exec_byte_code+1812>, 0x5555558f818a <exec_byte_code+5052>, 0x5555558f8232 <exec_byte_code+5220>, 0x5555558f82d7 <exec_byte_code+5385>, 0x5555558f837c <exec_byte_code+5550>, 0x5555558f852b <exec_byte_code+5981>, 0x5555558f7ac2 <exec_byte_code+3316>, 0x5555558f8617 <exec_byte_code+6217>, 0x5555558f869d <exec_byte_code+6351>, 0x5555558f8746 <exec_byte_code+6520>, 0x5555558f879b <exec_byte_code+6605>, 0x5555558f8a6c <exec_byte_code+7326>, 0x5555558f8afb <exec_byte_code+7469>, 0x5555558f8ba1 <exec_byte_code+7635>, 0x5555558f8c1c <exec_byte_code+7758>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fbbd7 <exec_byte_code+19977>, 0x5555558fbc7d <exec_byte_code+20143>, 0x5555558fbcda <exec_byte_code+20236>, 0x5555558fbd37 <exec_byte_code+20329>, 0x5555558fbd94 <exec_byte_code+20422>, 0x5555558fbdf1 <exec_byte_code+20515>, 0x5555558fbe74 <exec_byte_code+20646>, 0x5555558fbef7 <exec_byte_code+20777>, 0x5555558fbf7a <exec_byte_code+20908>, 0x5555558fbffd <exec_byte_code+21039>, 0x5555558fc22f <exec_byte_code+21601>, 0x5555558fc2b2 <exec_byte_code+21732>, 0x5555558fc335 <exec_byte_code+21863>, 0x5555558fc392 <exec_byte_code+21956>, 0x5555558fc4eb <exec_byte_code+22301>, 0x5555558fc644 <exec_byte_code+22646>, 0x5555558fc6a1 <exec_byte_code+22739>, 0x5555558fc6fe <exec_byte_code+22832>, 0x5555558facd6 <exec_byte_code+16136>, 0x5555558faea0 <exec_byte_code+16594>, 0x5555558fc765 <exec_byte_code+22935>, 0x5555558fc7e9 <exec_byte_code+23067>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558f940a <exec_byte_code+9788>, 0x5555558f9ce2 <exec_byte_code+12052>, 0x5555558fb149 <exec_byte_code+17275>, 0x5555558fca66 <exec_byte_code+23704>, 0x5555558fcaf6 <exec_byte_code+23848>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fcbaf <exec_byte_code+24033>, 0x5555558fcc60 <exec_byte_code+24210>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fcdd3 <exec_byte_code+24581> <repeats 64 times>}
quitcounter = 1 '\001'
bc = 0x555556024fb0 <main_thread+496>
top = 0x7ffff15ff288
pc = 0x7ffff26e973c "\210.\006\266\005\334\006\b!\210\004\204", <incomplete sequence \335>
bytestr = {i = 0x7ffff1e8c1ec}
vector = {i = 0x7ffff1e8c0dd}
maxdepth = {i = 0x12}
const_length = 3
bytestr_length = 7
vectorp = 0x7ffff1f55900
max_stack = 4
frame_base = 0x7ffff15ff2d8
fp = 0x7ffff15ff2f8
bytestr_data = 0x7ffff26e9685 "\306\005!\204\023"
rest = false
mandatory = 1
nonrest = 1
pushedargs = 1
result = {i = 0x7ffff2208a5d}
#15 0x000055555589058c in fetch_and_exec_byte_code (fun=..., args_template=1282, nargs=4, args=0x7fffffffca38) at eval.c:3098
#16 0x0000555555890a38 in funcall_lambda (fun=..., nargs=4, arg_vector=0x7fffffffca38) at eval.c:3170
val = {i = 0x2aaa9be91ee8}
syms_left = {i = 0x140a}
next = {i = 0x555555884cfc <make_lisp_symbol+61>}
lexenv = {i = 0x7fffffffc930}
count = {bytes = 544}
i = 132908406920
optional = false
rest = false
previous_rest = false
#17 0x000055555588fc04 in funcall_general (fun=..., numargs=4, args=0x7fffffffca38) at eval.c:2962
original_fun = {i = 0x2aaa9be91ee8}
#18 0x000055555588ff18 in Ffuncall (nargs=5, args=0x7fffffffca30) at eval.c:3012
count = {bytes = 512}
val = {i = 0x7265766e6f632d65}
#19 0x00005555558d3243 in call4 (fn=..., arg1=..., arg2=..., arg3=..., arg4=...) at /home/yantar92/Git/emacs/src/lisp.h:3270
#20 0x00005555558d7841 in Fload (file=..., noerror=..., nomessage=..., nosuffix=..., must_suffix=...) at lread.c:1680
val = {i = 0x0}
stream = 0x0
fd = 4
fd_index = {bytes = 352}
count = {bytes = 352}
found = {i = 0x5555561eb224}
efound = {i = 0x5555557f94f2 <builtin_lisp_symbol+48>}
hist_file_name = {i = 0x5555561eb224}
newer = false
compiled = false
handler = {i = 0x0}
fmode = 0x555555a4355e "r"
version = 0
no_native = false
is_module = false
is_native_elisp = false
found_eff = {i = 0x5555561eb224}
is_elc = false
input = {stream = 0x7ffff2dcabe3, lookahead = -117 '\213', buf = "%S\362\377"}
#21 0x000055555589027b in funcall_subr (subr=0x555556037ce0 <Sload>, numargs=3, args=0x7ffff15ff1b0) at eval.c:3059
argbuf = {{i = 0x5555561eaef4}, {i = 0x0}, {i = 0x30}, {i = 0x0}, {i = 0x0}, {i = 0x7fffffffcd20}, {i = 0x5555558f6086 <SUBRP+29>}, {i = 0x555556037ce5 <Sload+5>}}
a = 0x7fffffffcce0
fun = {i = 0x0}
#22 0x00005555558f7ed4 in exec_byte_code (fun=..., args_template=769, nargs=3, args=0x7ffff15ff3f0) at bytecode.c:815
call_nargs = 3
call_fun = {i = 0x555556037ce5 <Sload+5>}
count1 = {bytes = 320}
template = {i = 0xc06}
val = {i = 0x30}
call_args = 0x7ffff15ff1b0
original_fun = {i = 0xafb0}
bytecode = {i = 0x7ffff228b3dc}
op = 3
type = CONDITION_CASE
targets = {0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc89e <exec_byte_code+23248>, 0x5555558fc8a0 <exec_byte_code+23250>, 0x5555558fc8a2 <exec_byte_code+23252>, 0x5555558fc8a4 <exec_byte_code+23254>, 0x5555558fc8a4 <exec_byte_code+23254>, 0x5555558fc921 <exec_byte_code+23379>, 0x5555558fc9b0 <exec_byte_code+23522>, 0x5555558f737a <exec_byte_code+1452>, 0x5555558f737c <exec_byte_code+1454>, 0x5555558f737e <exec_byte_code+1456>, 0x5555558f7380 <exec_byte_code+1458>, 0x5555558f7382 <exec_byte_code+1460>, 0x5555558f7382 <exec_byte_code+1460>, 0x5555558f738b <exec_byte_code+1469>, 0x5555558f7337 <exec_byte_code+1385>, 0x5555558f78e8 <exec_byte_code+2842>, 0x5555558f78ea <exec_byte_code+2844>, 0x5555558f78ec <exec_byte_code+2846>, 0x5555558f78ee <exec_byte_code+2848>, 0x5555558f78f0 <exec_byte_code+2850>, 0x5555558f78f0 <exec_byte_code+2850>, 0x5555558f793a <exec_byte_code+2924>, 0x5555558f78f9 <exec_byte_code+2859>, 0x5555558f7b8b <exec_byte_code+3517>, 0x5555558f7b8d <exec_byte_code+3519>, 0x5555558f7b8f <exec_byte_code+3521>, 0x5555558f7b91 <exec_byte_code+3523>, 0x5555558f7b93 <exec_byte_code+3525>, 0x5555558f7b93 <exec_byte_code+3525>, 0x5555558f7b2a <exec_byte_code+3420>, 0x5555558f7b4a <exec_byte_code+3452>, 0x5555558f7c77 <exec_byte_code+3753>, 0x5555558f7c79 <exec_byte_code+3755>, 0x5555558f7c7b <exec_byte_code+3757>, 0x5555558f7c7d <exec_byte_code+3759>, 0x5555558f7c7f <exec_byte_code+3761>, 0x5555558f7c7f <exec_byte_code+3761>, 0x5555558f7c16 <exec_byte_code+3656>, 0x5555558f7c36 <exec_byte_code+3688>, 0x5555558f802c <exec_byte_code+4702>, 0x5555558f802e <exec_byte_code+4704>, 0x5555558f8030 <exec_byte_code+4706>, 0x5555558f8032 <exec_byte_code+4708>, 0x5555558f8034 <exec_byte_code+4710>, 0x5555558f8034 <exec_byte_code+4710>, 0x5555558f7fcb <exec_byte_code+4605>, 0x5555558f7feb <exec_byte_code+4637>, 0x5555558f8a14 <exec_byte_code+7238>, 0x5555558f8831 <exec_byte_code+6755>, 0x5555558f8825 <exec_byte_code+6743>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558f8cc5 <exec_byte_code+7927>, 0x5555558f8ee2 <exec_byte_code+8468>, 0x5555558f8f66 <exec_byte_code+8600>, 0x5555558f8fe8 <exec_byte_code+8730>, 0x5555558f906c <exec_byte_code+8862>, 0x5555558f76a9 <exec_byte_code+2267>, 0x5555558f7753 <exec_byte_code+2437>, 0x5555558f910a <exec_byte_code+9020>, 0x5555558f7598 <exec_byte_code+1994>, 0x5555558f77d6 <exec_byte_code+2568>, 0x5555558f9194 <exec_byte_code+9158>, 0x5555558f9217 <exec_byte_code+9289>, 0x5555558f9274 <exec_byte_code+9382>, 0x5555558f92f7 <exec_byte_code+9513>, 0x5555558f937b <exec_byte_code+9645>, 0x5555558f94ac <exec_byte_code+9950>, 0x5555558f9509 <exec_byte_code+10043>, 0x5555558f96d0 <exec_byte_code+10498>, 0x5555558f98c4 <exec_byte_code+10998>, 0x5555558f9921 <exec_byte_code+11091>, 0x5555558f997e <exec_byte_code+11184>, 0x5555558f9a01 <exec_byte_code+11315>, 0x5555558f9a84 <exec_byte_code+11446>, 0x5555558f9b07 <exec_byte_code+11577>, 0x5555558f9bad <exec_byte_code+11743>, 0x5555558f9c14 <exec_byte_code+11846>, 0x5555558f9c7b <exec_byte_code+11949>, 0x5555558f9d84 <exec_byte_code+12214>, 0x5555558f9ea3 <exec_byte_code+12501>, 0x5555558f9fc2 <exec_byte_code+12788>, 0x5555558fa0c2 <exec_byte_code+13044>, 0x5555558fa1d2 <exec_byte_code+13316>, 0x5555558fa2e2 <exec_byte_code+13588>, 0x5555558fa3f2 <exec_byte_code+13860>, 0x5555558fa502 <exec_byte_code+14132>, 0x5555558fa68d <exec_byte_code+14527>, 0x5555558fa7ad <exec_byte_code+14815>, 0x5555558fa944 <exec_byte_code+15222>, 0x5555558faa2b <exec_byte_code+15453>, 0x5555558fab12 <exec_byte_code+15684>, 0x5555558fb01d <exec_byte_code+16975>, 0x5555558f865a <exec_byte_code+6284>, 0x5555558fb08d <exec_byte_code+17087>, 0x5555558fb0ea <exec_byte_code+17180>, 0x5555558fb1eb <exec_byte_code+17437>, 0x5555558fb25b <exec_byte_code+17549>, 0x5555558fb2cb <exec_byte_code+17661>, 0x5555558fb328 <exec_byte_code+17754>, 0x5555558fb380 <exec_byte_code+17842>, 0x5555558fb3d8 <exec_byte_code+17930>, 0x5555558fb438 <exec_byte_code+18026>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fb4a5 <exec_byte_code+18135>, 0x5555558fb4fd <exec_byte_code+18223>, 0x5555558fb555 <exec_byte_code+18311>, 0x5555558fb5ad <exec_byte_code+18399>, 0x5555558fb605 <exec_byte_code+18487>, 0x5555558fb65d <exec_byte_code+18575>, 0x5555558f865a <exec_byte_code+6284>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fb6ba <exec_byte_code+18668>, 0x5555558fb71f <exec_byte_code+18769>, 0x5555558fb77c <exec_byte_code+18862>, 0x5555558fb7d9 <exec_byte_code+18955>, 0x5555558fb85c <exec_byte_code+19086>, 0x5555558fb8df <exec_byte_code+19217>, 0x5555558fb93c <exec_byte_code+19310>, 0x5555558fb999 <exec_byte_code+19403>, 0x5555558fba1c <exec_byte_code+19534>, 0x5555558fba9f <exec_byte_code+19665>, 0x5555558fbb22 <exec_byte_code+19796>, 0x5555558fbb7a <exec_byte_code+19884>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558f8571 <exec_byte_code+6051>, 0x5555558f80ac <exec_byte_code+4830>, 0x5555558f74e2 <exec_byte_code+1812>, 0x5555558f818a <exec_byte_code+5052>, 0x5555558f8232 <exec_byte_code+5220>, 0x5555558f82d7 <exec_byte_code+5385>, 0x5555558f837c <exec_byte_code+5550>, 0x5555558f852b <exec_byte_code+5981>, 0x5555558f7ac2 <exec_byte_code+3316>, 0x5555558f8617 <exec_byte_code+6217>, 0x5555558f869d <exec_byte_code+6351>, 0x5555558f8746 <exec_byte_code+6520>, 0x5555558f879b <exec_byte_code+6605>, 0x5555558f8a6c <exec_byte_code+7326>, 0x5555558f8afb <exec_byte_code+7469>, 0x5555558f8ba1 <exec_byte_code+7635>, 0x5555558f8c1c <exec_byte_code+7758>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fbbd7 <exec_byte_code+19977>, 0x5555558fbc7d <exec_byte_code+20143>, 0x5555558fbcda <exec_byte_code+20236>, 0x5555558fbd37 <exec_byte_code+20329>, 0x5555558fbd94 <exec_byte_code+20422>, 0x5555558fbdf1 <exec_byte_code+20515>, 0x5555558fbe74 <exec_byte_code+20646>, 0x5555558fbef7 <exec_byte_code+20777>, 0x5555558fbf7a <exec_byte_code+20908>, 0x5555558fbffd <exec_byte_code+21039>, 0x5555558fc22f <exec_byte_code+21601>, 0x5555558fc2b2 <exec_byte_code+21732>, 0x5555558fc335 <exec_byte_code+21863>, 0x5555558fc392 <exec_byte_code+21956>, 0x5555558fc4eb <exec_byte_code+22301>, 0x5555558fc644 <exec_byte_code+22646>, 0x5555558fc6a1 <exec_byte_code+22739>, 0x5555558fc6fe <exec_byte_code+22832>, 0x5555558facd6 <exec_byte_code+16136>, 0x5555558faea0 <exec_byte_code+16594>, 0x5555558fc765 <exec_byte_code+22935>, 0x5555558fc7e9 <exec_byte_code+23067>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558f940a <exec_byte_code+9788>, 0x5555558f9ce2 <exec_byte_code+12052>, 0x5555558fb149 <exec_byte_code+17275>, 0x5555558fca66 <exec_byte_code+23704>, 0x5555558fcaf6 <exec_byte_code+23848>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fcbaf <exec_byte_code+24033>, 0x5555558fcc60 <exec_byte_code+24210>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fc86d <exec_byte_code+23199>, 0x5555558fcdd3 <exec_byte_code+24581> <repeats 64 times>}
quitcounter = 26 '\032'
bc = 0x555556024fb0 <main_thread+496>
top = 0x7ffff15ff1a8
pc = 0x7ffff26c8f17 "\266\003\202z\003\353\002\206\n\002\n\211A\022\242!\352\001!\354\001!\357\001!\203\032\002\211\262\002\016A\360\232\203)\002\361\002!\266\004\202z\003\362\002!\266\004\202z\003\334\026B\001\206=\002\n\211A\022\242\262\n\006\t;\204I\002\335\363!\210\364\353\006\v!!\210\202z\003\016A\365\232\204a\002\016A\366\232\203m\002\001\204z\003\n\210\nA\022\202z\003\016A\367\267\202\202\002\370\334!\210\202z\003\371\372!\210\202z\003\324\373\016A\"\203\224\002\005\374\016A!\240\210\202z\003\324\375\016A\"\203\263\002\005\374\330\331\016A\"!\240\210\004\374\330\376\016A\"!\240\210\202z\003\337\003\r\"\211\262\v\203\307\002\006\tA@\n\233"...
bytestr = {i = 0x7ffff228b3dc}
vector = {i = 0x7ffff1e86655}
maxdepth = {i = 0x4a}
const_length = 36
bytestr_length = 342
vectorp = 0x7ffff2089f78
max_stack = 18
frame_base = 0x7ffff15ff430
fp = 0x7ffff15ff4c0
bytestr_data = 0x7ffff26c8d1c "\306 \210\b\203\034"
rest = false
mandatory = 1
nonrest = 3
pushedargs = 3
result = {i = 0x7ffff2426645}
#23 0x000055555589058c in fetch_and_exec_byte_code (fun=..., args_template=0, nargs=0, args=0x7fffffffd2c0) at eval.c:3098
#24 0x0000555555890a38 in funcall_lambda (fun=..., nargs=0, arg_vector=0x7fffffffd2c0) at eval.c:3170
val = {i = 0x0}
syms_left = {i = 0x2}
next = {i = 0x2aaa9bfb3da0}
lexenv = {i = 0x7fffffffd2c0}
count = {bytes = 160}
i = 128
optional = false
rest = false
previous_rest = false
#25 0x0000555555890729 in apply_lambda (fun=..., args=..., count=...) at eval.c:3120
arg_vector = 0x7fffffffd2c0
tem = {i = 0x7fffffffd330}
sa_avail = 16384
sa_count = {bytes = 160}
numargs = 0
args_left = {i = 0x0}
#26 0x000055555588e739 in eval_sub (form=...) at eval.c:2562
original_fun = {i = 0x2aaa9bfb3da0}
original_args = {i = 0x0}
count = {bytes = 128}
fun = {i = 0x7ffff2077775}
val = {i = 0x7fffffffd3a0}
funcar = {i = 0x5555560c39a0 <lispsym>}
argvals = {{i = 0x55555616e3b0}, {i = 0x5555560cd840 <lispsym+40608>}, {i = 0x555555885a64 <BUFFER_OBJFWDP+24>}, {i = 0x55555616e3b0}, {i = 0x7fffffffd440}, {i = 0x555555891fb9 <specbind+688>}, {i = 0x0}, {i = 0x9ea0}}
#27 0x000055555588da5f in Feval (form=..., lexical=...) at eval.c:2379
count = {bytes = 96}
#28 0x000055555579442c in top_level_2 () at keyboard.c:1166
#29 0x000055555588b0fd in internal_condition_case (bfun=0x555555794409 <top_level_2>, handlers=..., hfun=0x555555793beb <cmd_error>) at eval.c:1486
val = {i = 0x7fffffffd4f0}
c = 0x5555561ba700
#30 0x000055555579447d in top_level_1 (ignore=...) at keyboard.c:1174
#31 0x000055555588a1d3 in internal_catch (tag=..., func=0x55555579442e <top_level_1>, arg=...) at eval.c:1209
val = {i = 0x55555579012e <builtin_lisp_symbol+48>}
c = 0x5555561b22c0
#32 0x0000555555794342 in command_loop () at keyboard.c:1134
#33 0x000055555579368d in recursive_edit_1 () at keyboard.c:744
count = {bytes = 32}
val = {i = 0x555555892032 <record_unwind_protect+114>}
#34 0x00005555557938b9 in Frecursive_edit () at keyboard.c:827
count = {bytes = 0}
buffer = {i = 0x0}
#35 0x000055555578e813 in main (argc=5, argv=0x7fffffffd838) at emacs.c:2625
stack_bottom_variable = 0x21
old_argc = 5
dump_file = 0x0
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = 0x0
dump_mode = 0x0
skip_args = 1
temacs = 0x0
attempt_load_pdump = true
only_version = false
rlim = {rlim_cur = 10022912, rlim_max = 18446744073709551615}
lc_all = 0x0
sockfd = -1
module_assertions = false
(gdb) xbacktrace
Undefined command: "xbacktrace". Try "help".
In GNU Emacs 30.0.50 (build 22, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.18.0) of 2023-10-25 built on localhost
Repository revision: 8f00c9c3c6c4e76651c000e41582e002755e598b
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
System Description: Gentoo Linux
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-25 9:46 bug#66743: 30.0.50; Crash when dumping reftex Ihor Radchenko
@ 2023-10-25 12:46 ` Eli Zaretskii
2023-10-25 12:58 ` Ihor Radchenko
0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2023-10-25 12:46 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: 66743
> From: Ihor Radchenko <yantar92@posteo.net>
> Date: Wed, 25 Oct 2023 09:46:03 +0000
>
> Steps to reproduce:
>
> emacs -Q --batch -l dump.el
>
> with dump.el
>
> (dolist (feature
> '(reftex))
> (require feature))
> (dump-emacs-portable "/tmp/emacs-dumped.dmp")
>
> backtrace:
> [...]
> Program received signal SIGABRT, Aborted.
> 0x00007ffff58d3eac in ?? () from /lib64/libc.so.6
> (gdb) bt full
> #0 0x00007ffff58d3eac in () at /lib64/libc.so.6
> #1 0x00007ffff58855c2 in raise () at /lib64/libc.so.6
> #2 0x000055555578b242 in terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:484
> #3 0x00005555557cadde in emacs_abort () at sysdep.c:2391
> #4 0x00005555558563f7 in dump_buffer (ctx=0x7fffffffbeb0, in_buffer=0x7ffff1e62708) at pdumper.c:2866
The code which aborts:
if (!itree_empty_p (buffer->overlays))
/* We haven't implemented the code to dump overlays. */ <<<<<<<<<<
emacs_abort ();
Any questions?
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-25 12:46 ` Eli Zaretskii
@ 2023-10-25 12:58 ` Ihor Radchenko
2023-10-25 14:44 ` Stefan Kangas
2023-10-25 16:15 ` Gerd Möllmann
0 siblings, 2 replies; 32+ messages in thread
From: Ihor Radchenko @ 2023-10-25 12:58 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 66743
Eli Zaretskii <eliz@gnu.org> writes:
> The code which aborts:
>
> if (!itree_empty_p (buffer->overlays))
> /* We haven't implemented the code to dump overlays. */ <<<<<<<<<<
> emacs_abort ();
>
> Any questions?
What is the difficulty dumping overlays?
And, if it is hard, may we work around this by pdumper binding some flag
to non-nil and reftex.el hiding the overlay initialization code behind
an `if'?
At minimum, it would be helpful to print a message instead of crashing
into the user's face.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-25 12:58 ` Ihor Radchenko
@ 2023-10-25 14:44 ` Stefan Kangas
2023-10-26 9:31 ` Ihor Radchenko
2023-10-25 16:15 ` Gerd Möllmann
1 sibling, 1 reply; 32+ messages in thread
From: Stefan Kangas @ 2023-10-25 14:44 UTC (permalink / raw)
To: Ihor Radchenko, Eli Zaretskii; +Cc: 66743
severity 66743 wishlist
thanks
Ihor Radchenko <yantar92@posteo.net> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> The code which aborts:
>>
>> if (!itree_empty_p (buffer->overlays))
>> /* We haven't implemented the code to dump overlays. */ <<<<<<<<<<
>> emacs_abort ();
>>
>> Any questions?
I'm tagging this as wishlist, since this is a new feature. I hope
that's okay.
> At minimum, it would be helpful to print a message instead of crashing
> into the user's face.
Patches to do that are welcome, I think.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-25 12:58 ` Ihor Radchenko
2023-10-25 14:44 ` Stefan Kangas
@ 2023-10-25 16:15 ` Gerd Möllmann
2023-10-25 16:21 ` Eli Zaretskii
1 sibling, 1 reply; 32+ messages in thread
From: Gerd Möllmann @ 2023-10-25 16:15 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Eli Zaretskii, 66743
Ihor Radchenko <yantar92@posteo.net> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> The code which aborts:
>>
>> if (!itree_empty_p (buffer->overlays))
>> /* We haven't implemented the code to dump overlays. */ <<<<<<<<<<
>> emacs_abort ();
>>
>> Any questions?
>
> What is the difficulty dumping overlays?
If you are not trying to dump buffers, I think you won't need overlays.
So, the question is why dump buffers?
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-25 16:15 ` Gerd Möllmann
@ 2023-10-25 16:21 ` Eli Zaretskii
2023-10-25 16:37 ` Gerd Möllmann
0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2023-10-25 16:21 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: yantar92, 66743
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 66743@debbugs.gnu.org
> Date: Wed, 25 Oct 2023 18:15:44 +0200
>
> Ihor Radchenko <yantar92@posteo.net> writes:
>
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >> The code which aborts:
> >>
> >> if (!itree_empty_p (buffer->overlays))
> >> /* We haven't implemented the code to dump overlays. */ <<<<<<<<<<
> >> emacs_abort ();
> >>
> >> Any questions?
> >
> > What is the difficulty dumping overlays?
>
> If you are not trying to dump buffers, I think you won't need overlays.
> So, the question is why dump buffers?
Emacs is always dumped with a few buffers, because temacs needs them
to do the dumping. See this comment text from buffer.c:
Implementation notes: the buffers we carry from temacs are:
" prin1", "*scratch*", " *Minibuf-0*", "*Messages*", and
" *code-conversion-work*". They are created by
init_buffer_once and init_window_once (which are not called
in the dumped Emacs), and by the first call to coding.c
routines.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-25 16:21 ` Eli Zaretskii
@ 2023-10-25 16:37 ` Gerd Möllmann
2023-10-26 7:03 ` Gerd Möllmann
0 siblings, 1 reply; 32+ messages in thread
From: Gerd Möllmann @ 2023-10-25 16:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: yantar92, 66743
Eli Zaretskii <eliz@gnu.org> writes:
> Emacs is always dumped with a few buffers, because temacs needs them
> to do the dumping. See this comment text from buffer.c:
>
> Implementation notes: the buffers we carry from temacs are:
> " prin1", "*scratch*", " *Minibuf-0*", "*Messages*", and
> " *code-conversion-work*". They are created by
> init_buffer_once and init_window_once (which are not called
> in the dumped Emacs), and by the first call to coding.c
> routines.
Thanks.
So, one idea would be to try and move the creation of these buffers from
the init_*_once functions to the "normal" init functions, and see what
happens. One would also have to take a closer look at coding.c, of course.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-25 16:37 ` Gerd Möllmann
@ 2023-10-26 7:03 ` Gerd Möllmann
2023-10-26 7:35 ` Eli Zaretskii
2023-10-26 9:38 ` Ihor Radchenko
0 siblings, 2 replies; 32+ messages in thread
From: Gerd Möllmann @ 2023-10-26 7:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: yantar92, 66743
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Emacs is always dumped with a few buffers, because temacs needs them
>> to do the dumping. See this comment text from buffer.c:
>>
>> Implementation notes: the buffers we carry from temacs are:
>> " prin1", "*scratch*", " *Minibuf-0*", "*Messages*", and
>> " *code-conversion-work*". They are created by
>> init_buffer_once and init_window_once (which are not called
>> in the dumped Emacs), and by the first call to coding.c
>> routines.
>
> Thanks.
>
> So, one idea would be to try and move the creation of these buffers from
> the init_*_once functions to the "normal" init functions, and see what
> happens. One would also have to take a closer look at coding.c, of course.
Actually, this is bug#59029, sort of.
TLDR is that the code to dump itrees is there, somewhere in git, but has
an infinite recursion bug. So, I guess it should first be tried to
revive that code and fix it (tests should also exist, IIUC).
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-26 7:03 ` Gerd Möllmann
@ 2023-10-26 7:35 ` Eli Zaretskii
2023-10-26 8:04 ` Gerd Möllmann
2023-10-26 9:38 ` Ihor Radchenko
1 sibling, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2023-10-26 7:35 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: yantar92, 66743
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: yantar92@posteo.net, 66743@debbugs.gnu.org
> Date: Thu, 26 Oct 2023 09:03:33 +0200
>
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >> Emacs is always dumped with a few buffers, because temacs needs them
> >> to do the dumping. See this comment text from buffer.c:
> >>
> >> Implementation notes: the buffers we carry from temacs are:
> >> " prin1", "*scratch*", " *Minibuf-0*", "*Messages*", and
> >> " *code-conversion-work*". They are created by
> >> init_buffer_once and init_window_once (which are not called
> >> in the dumped Emacs), and by the first call to coding.c
> >> routines.
> >
> > Thanks.
> >
> > So, one idea would be to try and move the creation of these buffers from
> > the init_*_once functions to the "normal" init functions, and see what
> > happens. One would also have to take a closer look at coding.c, of course.
>
> Actually, this is bug#59029, sort of.
>
> TLDR is that the code to dump itrees is there, somewhere in git, but has
> an infinite recursion bug. So, I guess it should first be tried to
> revive that code and fix it (tests should also exist, IIUC).
Feel free to do that, of course.
However, from where I stand, we should first find and fix the other
bugs caused by re-dumping, of the kinds described in bugs 66741 and
66742 (there are more problems like that). Ideally, we need to
understand why these problems happen, and develop a protocol for
initializing things in a way that avoids such problems. Only after
that should we turn our attention to more specific aspects like itrees
etc. We should also have some policy for what should never be dumped,
I think -- those will have to be nullified or deleted before dumping.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-26 7:35 ` Eli Zaretskii
@ 2023-10-26 8:04 ` Gerd Möllmann
0 siblings, 0 replies; 32+ messages in thread
From: Gerd Möllmann @ 2023-10-26 8:04 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: yantar92, 66743
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: yantar92@posteo.net, 66743@debbugs.gnu.org
>> Date: Thu, 26 Oct 2023 09:03:33 +0200
>>
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>
>> > Eli Zaretskii <eliz@gnu.org> writes:
>> >
>> >> Emacs is always dumped with a few buffers, because temacs needs them
>> >> to do the dumping. See this comment text from buffer.c:
>> >>
>> >> Implementation notes: the buffers we carry from temacs are:
>> >> " prin1", "*scratch*", " *Minibuf-0*", "*Messages*", and
>> >> " *code-conversion-work*". They are created by
>> >> init_buffer_once and init_window_once (which are not called
>> >> in the dumped Emacs), and by the first call to coding.c
>> >> routines.
>> >
>> > Thanks.
>> >
>> > So, one idea would be to try and move the creation of these buffers from
>> > the init_*_once functions to the "normal" init functions, and see what
>> > happens. One would also have to take a closer look at coding.c, of course.
>>
>> Actually, this is bug#59029, sort of.
>>
>> TLDR is that the code to dump itrees is there, somewhere in git, but has
>> an infinite recursion bug. So, I guess it should first be tried to
>> revive that code and fix it (tests should also exist, IIUC).
>
> Feel free to do that, of course.
It's only a maybe from me, so far :-). I mainly chimed in because I know
the pdumper from dumping CL packages, and I also know a bit about
itrees.
BTW, it turns out the code is actually already in master
(dump_interval_node), but isn't executed because of the abort.
> However, from where I stand, we should first find and fix the other
> bugs caused by re-dumping, of the kinds described in bugs 66741 and
> 66742 (there are more problems like that). Ideally, we need to
> understand why these problems happen, and develop a protocol for
> initializing things in a way that avoids such problems. Only after
> that should we turn our attention to more specific aspects like itrees
> etc. We should also have some policy for what should never be dumped,
> I think -- those will have to be nullified or deleted before dumping.
Of course.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-25 14:44 ` Stefan Kangas
@ 2023-10-26 9:31 ` Ihor Radchenko
2023-10-26 10:01 ` Gerd Möllmann
0 siblings, 1 reply; 32+ messages in thread
From: Ihor Radchenko @ 2023-10-26 9:31 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Eli Zaretskii, 66743
Stefan Kangas <stefankangas@gmail.com> writes:
>> At minimum, it would be helpful to print a message instead of crashing
>> into the user's face.
>
> Patches to do that are welcome, I think.
May you please point me to a way to output warning to stderr from inside
pdumper code?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-26 7:03 ` Gerd Möllmann
2023-10-26 7:35 ` Eli Zaretskii
@ 2023-10-26 9:38 ` Ihor Radchenko
2023-10-26 9:44 ` Eli Zaretskii
1 sibling, 1 reply; 32+ messages in thread
From: Ihor Radchenko @ 2023-10-26 9:38 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Eli Zaretskii, 66743
[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>> Emacs is always dumped with a few buffers, because temacs needs them
>>> to do the dumping. See this comment text from buffer.c:
>>>
>>> Implementation notes: the buffers we carry from temacs are:
>>> " prin1", "*scratch*", " *Minibuf-0*", "*Messages*", and
>>> " *code-conversion-work*". They are created by
>>> init_buffer_once and init_window_once (which are not called
>>> in the dumped Emacs), and by the first call to coding.c
>>> routines.
>>
>> Thanks.
>>
>> So, one idea would be to try and move the creation of these buffers from
>> the init_*_once functions to the "normal" init functions, and see what
>> happens. One would also have to take a closer look at coding.c, of course.
>
> Actually, this is bug#59029, sort of.
>
> TLDR is that the code to dump itrees is there, somewhere in git, but has
> an infinite recursion bug. So, I guess it should first be tried to
> revive that code and fix it (tests should also exist, IIUC).
While I agree that dumping buffer overlays would be nice to have, I
think I found a simple workaround for the specific issue I reported.
We may simply make sure that the overlays do not belong to any buffer -
it is good enough for the purposes of reftex library, where the overlay
objects are created once and then modified by side effect for actual
use.
See the attached patch.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-textmodes-reftex.el-Work-around-pdumper-crash-b.patch --]
[-- Type: text/x-patch, Size: 1709 bytes --]
From 3bc99957796a8e8f92c8cb57d7102ee0461b3d86 Mon Sep 17 00:00:00 2001
Message-ID: <3bc99957796a8e8f92c8cb57d7102ee0461b3d86.1698313010.git.yantar92@posteo.net>
From: Ihor Radchenko <yantar92@posteo.net>
Date: Thu, 26 Oct 2023 12:34:58 +0300
Subject: [PATCH] * lisp/textmodes/reftex.el: Work around pdumper crash
(bug#66743)
(reftex-highlight-overlays): Make sure that the overlays objects are
not assigned to any buffer. This is to work around pdumping not
supporting dumping buffer overlays (yet).
---
lisp/textmodes/reftex.el | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/lisp/textmodes/reftex.el b/lisp/textmodes/reftex.el
index 0a1fa8580d0..5f564b7f9eb 100644
--- a/lisp/textmodes/reftex.el
+++ b/lisp/textmodes/reftex.el
@@ -2075,13 +2075,15 @@ 'reftex-delete-overlay
(defvar reftex-highlight-overlays [nil nil nil])
;; Initialize the overlays
-(aset reftex-highlight-overlays 0 (make-overlay 1 1))
+;; Ensure that the overlays are not assigned to any buffer to avoid
+;; crashing pdumper, if it is used to dump this library. See bug#66743.
+(aset reftex-highlight-overlays 0 (with-temp-buffer (make-overlay 1 1)))
(overlay-put (aref reftex-highlight-overlays 0)
'face 'highlight)
-(aset reftex-highlight-overlays 1 (make-overlay 1 1))
+(aset reftex-highlight-overlays 1 (with-temp-buffer (make-overlay 1 1)))
(overlay-put (aref reftex-highlight-overlays 1)
'face reftex-cursor-selected-face)
-(aset reftex-highlight-overlays 2 (make-overlay 1 1))
+(aset reftex-highlight-overlays 2 (with-temp-buffer (make-overlay 1 1)))
(overlay-put (aref reftex-highlight-overlays 2)
'face reftex-cursor-selected-face)
--
2.42.0
[-- Attachment #3: Type: text/plain, Size: 224 bytes --]
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply related [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-26 9:38 ` Ihor Radchenko
@ 2023-10-26 9:44 ` Eli Zaretskii
0 siblings, 0 replies; 32+ messages in thread
From: Eli Zaretskii @ 2023-10-26 9:44 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: gerd.moellmann, 66743
> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, 66743@debbugs.gnu.org
> Date: Thu, 26 Oct 2023 09:38:40 +0000
>
> > TLDR is that the code to dump itrees is there, somewhere in git, but has
> > an infinite recursion bug. So, I guess it should first be tried to
> > revive that code and fix it (tests should also exist, IIUC).
>
> While I agree that dumping buffer overlays would be nice to have, I
> think I found a simple workaround for the specific issue I reported.
> We may simply make sure that the overlays do not belong to any buffer -
> it is good enough for the purposes of reftex library, where the overlay
> objects are created once and then modified by side effect for actual
> use.
>
> See the attached patch.
Thanks.
FWIW, I'd prefer that we find less kludgey solutions to these
problems.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-26 9:31 ` Ihor Radchenko
@ 2023-10-26 10:01 ` Gerd Möllmann
2023-10-26 11:55 ` Ihor Radchenko
0 siblings, 1 reply; 32+ messages in thread
From: Gerd Möllmann @ 2023-10-26 10:01 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Eli Zaretskii, 66743, Stefan Kangas
Ihor Radchenko <yantar92@posteo.net> writes:
> Stefan Kangas <stefankangas@gmail.com> writes:
>
>>> At minimum, it would be helpful to print a message instead of crashing
>>> into the user's face.
>>
>> Patches to do that are welcome, I think.
>
> May you please point me to a way to output warning to stderr from inside
> pdumper code?
fprintf (stderr, ...) I'd say.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-26 10:01 ` Gerd Möllmann
@ 2023-10-26 11:55 ` Ihor Radchenko
2023-10-26 12:08 ` Eli Zaretskii
0 siblings, 1 reply; 32+ messages in thread
From: Ihor Radchenko @ 2023-10-26 11:55 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Eli Zaretskii, 66743, Stefan Kangas
[-- Attachment #1: Type: text/plain, Size: 305 bytes --]
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>> Patches to do that are welcome, I think.
>>
>> May you please point me to a way to output warning to stderr from inside
>> pdumper code?
>
> fprintf (stderr, ...) I'd say.
That's more obvious than I thought :)
See the attached patch.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-src-pdumper.c-dump_buffer-Print-message-before-abort.patch --]
[-- Type: text/x-patch, Size: 1179 bytes --]
From c777b76ec544b33cd94e0d945554b9c6aeb785f1 Mon Sep 17 00:00:00 2001
Message-ID: <c777b76ec544b33cd94e0d945554b9c6aeb785f1.1698321284.git.yantar92@posteo.net>
From: Ihor Radchenko <yantar92@posteo.net>
Date: Thu, 26 Oct 2023 14:52:32 +0300
Subject: [PATCH] * src/pdumper.c (dump_buffer): Print message before aborting
(bug#66743)
When the buffer contains overlays, it cannot be dumped. Print a
message describing this fact before aborting Emacs.
---
src/pdumper.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/pdumper.c b/src/pdumper.c
index 315a31e2bcb..cd5a50f9b48 100644
--- a/src/pdumper.c
+++ b/src/pdumper.c
@@ -2862,8 +2862,11 @@ dump_buffer (struct dump_context *ctx, const struct buffer *in_buffer)
DUMP_FIELD_COPY (out, buffer, long_line_optimizations_p);
if (!itree_empty_p (buffer->overlays))
- /* We haven't implemented the code to dump overlays. */
- emacs_abort ();
+ {
+ /* We haven't implemented the code to dump overlays. */
+ fprintf(stderr, "Dumping overlays in buffers is not yet implemented. Aborting...\n");
+ emacs_abort ();
+ }
else
out->overlays = NULL;
--
2.42.0
[-- Attachment #3: Type: text/plain, Size: 224 bytes --]
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply related [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-26 11:55 ` Ihor Radchenko
@ 2023-10-26 12:08 ` Eli Zaretskii
2023-10-26 12:14 ` Ihor Radchenko
0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2023-10-26 12:08 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: gerd.moellmann, 66743, stefankangas
> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Stefan Kangas <stefankangas@gmail.com>, Eli Zaretskii <eliz@gnu.org>,
> 66743@debbugs.gnu.org
> Date: Thu, 26 Oct 2023 11:55:38 +0000
>
> >> May you please point me to a way to output warning to stderr from inside
> >> pdumper code?
> >
> > fprintf (stderr, ...) I'd say.
>
> That's more obvious than I thought :)
>
> See the attached patch.
If you are suggesting this for upstream, then it's not optimal, at
least in interactive session: the stderr stream is usually redirected
to some bottomless OS pit where no one could see it.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-26 12:08 ` Eli Zaretskii
@ 2023-10-26 12:14 ` Ihor Radchenko
2023-10-26 13:04 ` Eli Zaretskii
0 siblings, 1 reply; 32+ messages in thread
From: Ihor Radchenko @ 2023-10-26 12:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gerd.moellmann, 66743, stefankangas
Eli Zaretskii <eliz@gnu.org> writes:
>> See the attached patch.
>
> If you are suggesting this for upstream, then it's not optimal, at
> least in interactive session: the stderr stream is usually redirected
> to some bottomless OS pit where no one could see it.
`dump-emacs-portable' does not work in interactive sessions:
if (! noninteractive)
error ("Dumping Emacs currently works only in batch mode. "
"If you'd like it to work interactively, please consider "
"contributing a patch to Emacs.");
If you mean that `dump-emacs-portable' should be made interactive, it is
a much harder task as many emacs_abort (); calls in pdumper.c would need
to be changed to something suitable for interactive sessions.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-26 12:14 ` Ihor Radchenko
@ 2023-10-26 13:04 ` Eli Zaretskii
2023-10-26 13:13 ` Ihor Radchenko
0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2023-10-26 13:04 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: gerd.moellmann, 66743, stefankangas
> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: gerd.moellmann@gmail.com, stefankangas@gmail.com, 66743@debbugs.gnu.org
> Date: Thu, 26 Oct 2023 12:14:08 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> See the attached patch.
> >
> > If you are suggesting this for upstream, then it's not optimal, at
> > least in interactive session: the stderr stream is usually redirected
> > to some bottomless OS pit where no one could see it.
>
> `dump-emacs-portable' does not work in interactive sessions:
And we don't want it to work?
> if (! noninteractive)
> error ("Dumping Emacs currently works only in batch mode. "
> "If you'd like it to work interactively, please consider "
> "contributing a patch to Emacs.");
>
> If you mean that `dump-emacs-portable' should be made interactive, it is
> a much harder task as many emacs_abort (); calls in pdumper.c would need
> to be changed to something suitable for interactive sessions.
And then we will need to remember to change this fprintf as well?
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-26 13:04 ` Eli Zaretskii
@ 2023-10-26 13:13 ` Ihor Radchenko
2023-10-26 13:18 ` Eli Zaretskii
0 siblings, 1 reply; 32+ messages in thread
From: Ihor Radchenko @ 2023-10-26 13:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gerd.moellmann, 66743, stefankangas
Eli Zaretskii <eliz@gnu.org> writes:
>> If you mean that `dump-emacs-portable' should be made interactive, it is
>> a much harder task as many emacs_abort (); calls in pdumper.c would need
>> to be changed to something suitable for interactive sessions.
>
> And then we will need to remember to change this fprintf as well?
Yes. Just as the other printfs in pdumper.c. There are 4 more.
I do not see a problem.
... unless someone is up to actually implementing interactive version of
`dump-emacs-portable'. But that would first require implementing buffer
overlay dumps (many interactive sessions will likely have those). Not
trivial.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-26 13:13 ` Ihor Radchenko
@ 2023-10-26 13:18 ` Eli Zaretskii
2023-10-26 13:27 ` Ihor Radchenko
0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2023-10-26 13:18 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: gerd.moellmann, 66743, stefankangas
> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: gerd.moellmann@gmail.com, stefankangas@gmail.com, 66743@debbugs.gnu.org
> Date: Thu, 26 Oct 2023 13:13:43 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> If you mean that `dump-emacs-portable' should be made interactive, it is
> >> a much harder task as many emacs_abort (); calls in pdumper.c would need
> >> to be changed to something suitable for interactive sessions.
> >
> > And then we will need to remember to change this fprintf as well?
>
> Yes. Just as the other printfs in pdumper.c. There are 4 more.
> I do not see a problem.
I do (and there's only one other error-printing fprintf, not 4).
Please use higher-level facilities to show an error, so that we won't
need to find all those places. (Only if you want to propose this code
for installation in Emacs, of course.)
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-26 13:18 ` Eli Zaretskii
@ 2023-10-26 13:27 ` Ihor Radchenko
2023-10-26 13:28 ` Eli Zaretskii
0 siblings, 1 reply; 32+ messages in thread
From: Ihor Radchenko @ 2023-10-26 13:27 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gerd.moellmann, 66743, stefankangas
Eli Zaretskii <eliz@gnu.org> writes:
>> Yes. Just as the other printfs in pdumper.c. There are 4 more.
>> I do not see a problem.
>
> I do (and there's only one other error-printing fprintf, not 4).
> Please use higher-level facilities to show an error, so that we won't
> need to find all those places. (Only if you want to propose this code
> for installation in Emacs, of course.)
May you please point me to such higher-level facility?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-26 13:27 ` Ihor Radchenko
@ 2023-10-26 13:28 ` Eli Zaretskii
2023-10-26 13:48 ` Ihor Radchenko
0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2023-10-26 13:28 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: gerd.moellmann, 66743, stefankangas
> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: gerd.moellmann@gmail.com, stefankangas@gmail.com, 66743@debbugs.gnu.org
> Date: Thu, 26 Oct 2023 13:27:02 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> Yes. Just as the other printfs in pdumper.c. There are 4 more.
> >> I do not see a problem.
> >
> > I do (and there's only one other error-printing fprintf, not 4).
> > Please use higher-level facilities to show an error, so that we won't
> > need to find all those places. (Only if you want to propose this code
> > for installation in Emacs, of course.)
>
> May you please point me to such higher-level facility?
How about 'error'?
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-26 13:28 ` Eli Zaretskii
@ 2023-10-26 13:48 ` Ihor Radchenko
2023-10-26 15:49 ` Eli Zaretskii
0 siblings, 1 reply; 32+ messages in thread
From: Ihor Radchenko @ 2023-10-26 13:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gerd.moellmann, 66743, stefankangas
[-- Attachment #1: Type: text/plain, Size: 148 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> May you please point me to such higher-level facility?
>
> How about 'error'?
Thanks!
See the attached.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: v2-0001-src-pdumper.c-dump_buffer-Print-message-before-ab.patch --]
[-- Type: text/x-patch, Size: 1173 bytes --]
From c6c2b5a2f02c508fad3255033589d788ed84b09f Mon Sep 17 00:00:00 2001
Message-ID: <c6c2b5a2f02c508fad3255033589d788ed84b09f.1698328056.git.yantar92@posteo.net>
From: Ihor Radchenko <yantar92@posteo.net>
Date: Thu, 26 Oct 2023 14:52:32 +0300
Subject: [PATCH v2] * src/pdumper.c (dump_buffer): Print message before
aborting (bug#66743)
When the buffer contains overlays, it cannot be dumped. Print a
message describing this fact before aborting Emacs.
---
src/pdumper.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/pdumper.c b/src/pdumper.c
index 315a31e2bcb..62d4fbcd68b 100644
--- a/src/pdumper.c
+++ b/src/pdumper.c
@@ -2862,8 +2862,11 @@ dump_buffer (struct dump_context *ctx, const struct buffer *in_buffer)
DUMP_FIELD_COPY (out, buffer, long_line_optimizations_p);
if (!itree_empty_p (buffer->overlays))
- /* We haven't implemented the code to dump overlays. */
- emacs_abort ();
+ {
+ /* We haven't implemented the code to dump overlays. */
+ error ("Dumping overlays in buffers is not yet implemented. Aborting...\n");
+ emacs_abort ();
+ }
else
out->overlays = NULL;
--
2.42.0
[-- Attachment #3: Type: text/plain, Size: 224 bytes --]
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply related [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-26 13:48 ` Ihor Radchenko
@ 2023-10-26 15:49 ` Eli Zaretskii
2023-10-27 9:08 ` Ihor Radchenko
0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2023-10-26 15:49 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: gerd.moellmann, 66743, stefankangas
> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: gerd.moellmann@gmail.com, stefankangas@gmail.com, 66743@debbugs.gnu.org
> Date: Thu, 26 Oct 2023 13:48:47 +0000
>
> --- a/src/pdumper.c
> +++ b/src/pdumper.c
> @@ -2862,8 +2862,11 @@ dump_buffer (struct dump_context *ctx, const struct buffer *in_buffer)
> DUMP_FIELD_COPY (out, buffer, long_line_optimizations_p);
>
> if (!itree_empty_p (buffer->overlays))
> - /* We haven't implemented the code to dump overlays. */
> - emacs_abort ();
> + {
> + /* We haven't implemented the code to dump overlays. */
> + error ("Dumping overlays in buffers is not yet implemented. Aborting...\n");
> + emacs_abort ();
> + }
If you call 'error' in batch mode, do you really need emacs_abort?
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-26 15:49 ` Eli Zaretskii
@ 2023-10-27 9:08 ` Ihor Radchenko
2023-10-27 10:38 ` Eli Zaretskii
0 siblings, 1 reply; 32+ messages in thread
From: Ihor Radchenko @ 2023-10-27 9:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gerd.moellmann, 66743, stefankangas
[-- Attachment #1: Type: text/plain, Size: 607 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> + {
>> + /* We haven't implemented the code to dump overlays. */
>> + error ("Dumping overlays in buffers is not yet implemented. Aborting...\n");
>> + emacs_abort ();
>> + }
>
> If you call 'error' in batch mode, do you really need emacs_abort?
If `error' does all the necessary cleanup, `emacs_abort' is indeed not
necessary. But that's not very obvious from the source code.
See the attached patch with `emacs_abort` call removed.
I also removed the final newline, as it does not seem to be used in
other instances of error (...) calls.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: v3-0001-src-pdumper.c-dump_buffer-Print-message-when-abor.patch --]
[-- Type: text/x-patch, Size: 1145 bytes --]
From 18d896985e7373320afe8447cf836717797e5cb2 Mon Sep 17 00:00:00 2001
Message-ID: <18d896985e7373320afe8447cf836717797e5cb2.1698397578.git.yantar92@posteo.net>
From: Ihor Radchenko <yantar92@posteo.net>
Date: Thu, 26 Oct 2023 14:52:32 +0300
Subject: [PATCH v3] * src/pdumper.c (dump_buffer): Print message when aborting
(bug#66743)
When the buffer contains overlays, it cannot be dumped. Print a
message describing this fact before aborting Emacs.
---
src/pdumper.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/pdumper.c b/src/pdumper.c
index 315a31e2bcb..9a3870181e3 100644
--- a/src/pdumper.c
+++ b/src/pdumper.c
@@ -2862,8 +2862,10 @@ dump_buffer (struct dump_context *ctx, const struct buffer *in_buffer)
DUMP_FIELD_COPY (out, buffer, long_line_optimizations_p);
if (!itree_empty_p (buffer->overlays))
- /* We haven't implemented the code to dump overlays. */
- emacs_abort ();
+ {
+ /* We haven't implemented the code to dump overlays. */
+ error ("Dumping overlays in buffers is not yet implemented. Aborting...");
+ }
else
out->overlays = NULL;
--
2.42.0
[-- Attachment #3: Type: text/plain, Size: 224 bytes --]
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply related [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-27 9:08 ` Ihor Radchenko
@ 2023-10-27 10:38 ` Eli Zaretskii
2023-10-27 10:55 ` Ihor Radchenko
0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2023-10-27 10:38 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: gerd.moellmann, 66743, stefankangas
> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: gerd.moellmann@gmail.com, stefankangas@gmail.com, 66743@debbugs.gnu.org
> Date: Fri, 27 Oct 2023 09:08:02 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> + {
> >> + /* We haven't implemented the code to dump overlays. */
> >> + error ("Dumping overlays in buffers is not yet implemented. Aborting...\n");
> >> + emacs_abort ();
> >> + }
> >
> > If you call 'error' in batch mode, do you really need emacs_abort?
>
> If `error' does all the necessary cleanup, `emacs_abort' is indeed not
> necessary. But that's not very obvious from the source code.
What cleanup is needed in this case?
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-27 10:38 ` Eli Zaretskii
@ 2023-10-27 10:55 ` Ihor Radchenko
2023-10-27 11:01 ` Eli Zaretskii
0 siblings, 1 reply; 32+ messages in thread
From: Ihor Radchenko @ 2023-10-27 10:55 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gerd.moellmann, 66743, stefankangas
Eli Zaretskii <eliz@gnu.org> writes:
>> If `error' does all the necessary cleanup, `emacs_abort' is indeed not
>> necessary. But that's not very obvious from the source code.
>
> What cleanup is needed in this case?
I have no idea.
To be clear: I am not sure what is the difference between `emacs_abort'
and `error'. I just noted that there is some and thus did not dare to
touch the `emacs_abort' call to avoid unexpected breakage.
If you say that using `error' instead of `emacs_abort' is safe, I will
just follow. I expect that you know these details well.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-27 10:55 ` Ihor Radchenko
@ 2023-10-27 11:01 ` Eli Zaretskii
2023-10-27 11:09 ` Ihor Radchenko
0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2023-10-27 11:01 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: gerd.moellmann, 66743, stefankangas
> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: gerd.moellmann@gmail.com, stefankangas@gmail.com, 66743@debbugs.gnu.org
> Date: Fri, 27 Oct 2023 10:55:37 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> If `error' does all the necessary cleanup, `emacs_abort' is indeed not
> >> necessary. But that's not very obvious from the source code.
> >
> > What cleanup is needed in this case?
>
> I have no idea.
> To be clear: I am not sure what is the difference between `emacs_abort'
> and `error'.
AFAIU, in batch mode there's no difference, since calling 'error'
shows a backtrace and exits.
> If you say that using `error' instead of `emacs_abort' is safe, I will
> just follow. I expect that you know these details well.
I think it's safe, since we already do that in other places in
pdumper.c.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-27 11:01 ` Eli Zaretskii
@ 2023-10-27 11:09 ` Ihor Radchenko
2023-10-27 12:36 ` Eli Zaretskii
0 siblings, 1 reply; 32+ messages in thread
From: Ihor Radchenko @ 2023-10-27 11:09 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gerd.moellmann, 66743, stefankangas
Eli Zaretskii <eliz@gnu.org> writes:
>> If you say that using `error' instead of `emacs_abort' is safe, I will
>> just follow. I expect that you know these details well.
>
> I think it's safe, since we already do that in other places in
> pdumper.c.
Then, you may consider merging my v3 patch.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-27 11:09 ` Ihor Radchenko
@ 2023-10-27 12:36 ` Eli Zaretskii
2023-10-27 12:45 ` Ihor Radchenko
0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2023-10-27 12:36 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: gerd.moellmann, stefankangas, 66743-done
> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: gerd.moellmann@gmail.com, stefankangas@gmail.com, 66743@debbugs.gnu.org
> Date: Fri, 27 Oct 2023 11:09:40 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> If you say that using `error' instead of `emacs_abort' is safe, I will
> >> just follow. I expect that you know these details well.
> >
> > I think it's safe, since we already do that in other places in
> > pdumper.c.
>
> Then, you may consider merging my v3 patch.
Done, after some minor cleanup.
Thanks.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-27 12:36 ` Eli Zaretskii
@ 2023-10-27 12:45 ` Ihor Radchenko
2023-10-27 12:53 ` Eli Zaretskii
0 siblings, 1 reply; 32+ messages in thread
From: Ihor Radchenko @ 2023-10-27 12:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gerd.moellmann, stefankangas, 66743-done
Eli Zaretskii <eliz@gnu.org> writes:
>> Then, you may consider merging my v3 patch.
>
> Done, after some minor cleanup.
Thanks!
Although, I am not sure if this is enough to close the bug.
Maybe it should remain open until dumping buffer overlays is
implemented?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#66743: 30.0.50; Crash when dumping reftex
2023-10-27 12:45 ` Ihor Radchenko
@ 2023-10-27 12:53 ` Eli Zaretskii
0 siblings, 0 replies; 32+ messages in thread
From: Eli Zaretskii @ 2023-10-27 12:53 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: gerd.moellmann, stefankangas, 66743-done
> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: gerd.moellmann@gmail.com, stefankangas@gmail.com,
> 66743-done@debbugs.gnu.org
> Date: Fri, 27 Oct 2023 12:45:28 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> Then, you may consider merging my v3 patch.
> >
> > Done, after some minor cleanup.
>
> Thanks!
> Although, I am not sure if this is enough to close the bug.
> Maybe it should remain open until dumping buffer overlays is
> implemented?
Feel free to reopen or to file another bug specifically about dumping
overlays.
^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2023-10-27 12:53 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-25 9:46 bug#66743: 30.0.50; Crash when dumping reftex Ihor Radchenko
2023-10-25 12:46 ` Eli Zaretskii
2023-10-25 12:58 ` Ihor Radchenko
2023-10-25 14:44 ` Stefan Kangas
2023-10-26 9:31 ` Ihor Radchenko
2023-10-26 10:01 ` Gerd Möllmann
2023-10-26 11:55 ` Ihor Radchenko
2023-10-26 12:08 ` Eli Zaretskii
2023-10-26 12:14 ` Ihor Radchenko
2023-10-26 13:04 ` Eli Zaretskii
2023-10-26 13:13 ` Ihor Radchenko
2023-10-26 13:18 ` Eli Zaretskii
2023-10-26 13:27 ` Ihor Radchenko
2023-10-26 13:28 ` Eli Zaretskii
2023-10-26 13:48 ` Ihor Radchenko
2023-10-26 15:49 ` Eli Zaretskii
2023-10-27 9:08 ` Ihor Radchenko
2023-10-27 10:38 ` Eli Zaretskii
2023-10-27 10:55 ` Ihor Radchenko
2023-10-27 11:01 ` Eli Zaretskii
2023-10-27 11:09 ` Ihor Radchenko
2023-10-27 12:36 ` Eli Zaretskii
2023-10-27 12:45 ` Ihor Radchenko
2023-10-27 12:53 ` Eli Zaretskii
2023-10-25 16:15 ` Gerd Möllmann
2023-10-25 16:21 ` Eli Zaretskii
2023-10-25 16:37 ` Gerd Möllmann
2023-10-26 7:03 ` Gerd Möllmann
2023-10-26 7:35 ` Eli Zaretskii
2023-10-26 8:04 ` Gerd Möllmann
2023-10-26 9:38 ` Ihor Radchenko
2023-10-26 9:44 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).