bug#66743: 30.0.50; Crash when dumping reftex

bug#66743: 30.0.50; Crash when dumping reftex

[Ihor Radchenko]

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>

bug#66743: 30.0.50; Crash when dumping reftex

[Eli Zaretskii]

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

bug#66743: 30.0.50; Crash when dumping reftex

[Ihor Radchenko]

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>

bug#66743: 30.0.50; Crash when dumping reftex

[Stefan Kangas]

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.

bug#66743: 30.0.50; Crash when dumping reftex

[Gerd Möllmann]

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?

bug#66743: 30.0.50; Crash when dumping reftex

[Eli Zaretskii]

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

bug#66743: 30.0.50; Crash when dumping reftex

[Gerd Möllmann]

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.

bug#66743: 30.0.50; Crash when dumping reftex

[Gerd Möllmann]

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).

bug#66743: 30.0.50; Crash when dumping reftex

[Eli Zaretskii]

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

bug#66743: 30.0.50; Crash when dumping reftex

[Gerd Möllmann]

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.

bug#66743: 30.0.50; Crash when dumping reftex

[Ihor Radchenko]

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>

bug#66743: 30.0.50; Crash when dumping reftex

[Ihor Radchenko]

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

bug#66743: 30.0.50; Crash when dumping reftex

[Eli Zaretskii]

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

bug#66743: 30.0.50; Crash when dumping reftex

[Gerd Möllmann]

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.

bug#66743: 30.0.50; Crash when dumping reftex

[Ihor Radchenko]

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

bug#66743: 30.0.50; Crash when dumping reftex

[Eli Zaretskii]

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

bug#66743: 30.0.50; Crash when dumping reftex

[Ihor Radchenko]

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>

bug#66743: 30.0.50; Crash when dumping reftex

[Eli Zaretskii]

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

bug#66743: 30.0.50; Crash when dumping reftex

[Ihor Radchenko]

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>

bug#66743: 30.0.50; Crash when dumping reftex

[Eli Zaretskii]

> 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.)

bug#66743: 30.0.50; Crash when dumping reftex

[Ihor Radchenko]

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>

bug#66743: 30.0.50; Crash when dumping reftex

[Eli Zaretskii]

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

bug#66743: 30.0.50; Crash when dumping reftex

[Ihor Radchenko]

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

bug#66743: 30.0.50; Crash when dumping reftex

[Eli Zaretskii]

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

bug#66743: 30.0.50; Crash when dumping reftex

[Ihor Radchenko]

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

bug#66743: 30.0.50; Crash when dumping reftex

[Eli Zaretskii]

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

bug#66743: 30.0.50; Crash when dumping reftex

[Ihor Radchenko]

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>

bug#66743: 30.0.50; Crash when dumping reftex

[Eli Zaretskii]

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

bug#66743: 30.0.50; Crash when dumping reftex

[Ihor Radchenko]

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>

bug#66743: 30.0.50; Crash when dumping reftex

[Eli Zaretskii]

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

bug#66743: 30.0.50; Crash when dumping reftex

[Ihor Radchenko]

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>

bug#66743: 30.0.50; Crash when dumping reftex

[Eli Zaretskii]

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