Package: emacs;
Reported by: Óscar Fuentes <oscarfv <at> eclipso.eu>
Date: Wed, 30 Jul 2025 20:20:02 UTC
Severity: normal
Found in version 31.0.50
To reply to this bug, email your comments to 79131 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
pipcet <at> protonmail.com, gerd.moellmann <at> gmail.com, bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Wed, 30 Jul 2025 20:20:02 GMT) Full text and rfc822 format available.Óscar Fuentes <oscarfv <at> eclipso.eu>:pipcet <at> protonmail.com, gerd.moellmann <at> gmail.com, bug-gnu-emacs <at> gnu.org.
(Wed, 30 Jul 2025 20:20:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Óscar Fuentes <oscarfv <at> eclipso.eu> To: bug-gnu-emacs <at> gnu.org Subject: 31.0.50; igc: nested signal, SIGSEGV Date: Wed, 30 Jul 2025 22:18:44 +0200
This is a build of merging master's 6982dc460aa with current feature/igc
HEAD (382123e69e2). I had to resolve some conflicts, so there is a
possibility of the crash being caused by my mistake.
Backtrace from the coredump:
(gdb) bt full
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo <at> entry=11, no_tid=no_tid <at> entry=0)
at ./nptl/pthread_kill.c:44
tid = <optimized out>
ret = 0
pd = <optimized out>
old_mask = {__val = {94452575465120}}
ret = <optimized out>
#1 0x00007f506ce9e9ff in __pthread_kill_internal (threadid=<optimized out>, signo=11)
at ./nptl/pthread_kill.c:89
#2 0x00007f506ce49cc2 in __GI_raise (sig=sig <at> entry=11) at ../sysdeps/posix/raise.c:26
ret = <optimized out>
#3 0x000055e773f12db8 in terminate_due_to_signal
(sig=sig <at> entry=11, backtrace_limit=backtrace_limit <at> entry=40) at ../../emacs/src/emacs.c:481
#4 0x000055e773f132de in handle_fatal_signal (sig=sig <at> entry=11) at ../../emacs/src/sysdep.c:1793
#5 0x000055e773f132e5 in deliver_thread_signal
(sig=sig <at> entry=11, handler=0x55e773f132d0 <handle_fatal_signal>) at ../../emacs/src/sysdep.c:1785
old_errno = <optimized out>
#6 0x000055e774058dec in deliver_fatal_thread_signal (sig=11) at ../../emacs/src/sysdep.c:1805
#7 handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at ../../emacs/src/sysdep.c:1943
fatal = <optimized out>
#8 0x00007f506ce49df0 in <signal handler called> () at /lib/x86_64-linux-gnu/libc.so.6
#9 0x00007f506ce4a007 in __GI_kill () at ../sysdeps/unix/syscall-template.S:120
#10 0x000055e774215e44 in sigHandle ()
#11 0x00007f506ce49df0 in <signal handler called> () at /lib/x86_64-linux-gnu/libc.so.6
#12 add_text_properties_1 (start=<optimized out>, start <at> entry=0x1f06a, end=<optimized out>,
end <at> entry=0x1f07a, properties=0x7f4fe3c2acc3, object=0x7f4fe645cfbd,
object <at> entry=0x0, set_type=set_type <at> entry=TEXT_PROPERTY_REPLACE, destructive=destructive <at> entry=true)
--Type <RET> for more, q to quit, c to continue without paging--c
at ../../emacs/src/textprop.c:1252
i = 0x0
unchanged = <optimized out>
s = 31770
len = 3
modified = <optimized out>
first_time = <optimized out>
#13 0x000055e77414774b in Fadd_text_properties
(start=0x1f06a, end=0x1f07a, properties=<optimized out>, object=0x0) at ../../emacs/src/textprop.c:1308
#14 Fput_text_property
(start=0x1f06a, end=0x1f07a, property=<optimized out>, value=<optimized out>, object=0x0)
at ../../emacs/src/textprop.c:1326
properties = <optimized out>
#15 0x00007f505801aec2 in F747265657369742d2d666f6e742d6c6f636b2d6d61726b2d72616e6765732d746f2d666f6e74696679_treesit__font_lock_mark_ranges_to_fontify_0 ()
at /home/oscar/.emacs.d/eln-cache/31.0.50-3eae311e/treesit-37439c61-2c208e3a.eln
#16 0x000055e7740c8e8c in Ffuncall (nargs=2, args=0x7ffd6a2b0e70) at ../../emacs/src/eval.c:3201
count = {bytes = <optimized out>}
val = <optimized out>
#17 0x00007f505801b396 in F747265657369742d2d7072652d7265646973706c6179_treesit__pre_redisplay_0 ()
at /home/oscar/.emacs.d/eln-cache/31.0.50-3eae311e/treesit-37439c61-2c208e3a.eln
#18 0x000055e7740c8e8c in Ffuncall (nargs=2, args=0x7ffd6a2b0f80) at ../../emacs/src/eval.c:3201
count = {bytes = <optimized out>}
val = <optimized out>
#19 0x000055e7740c90e9 in funcall_nil (nargs=<optimized out>, args=<optimized out>)
at ../../emacs/src/eval.c:2884
#20 0x000055e7740c643d in run_hook_with_args
(nargs=2, args=0x7ffd6a2b0f80, funcall=0x55e7740c90e0 <funcall_nil>) at ../../emacs/src/eval.c:3061
global_vals = <optimized out>
sym = 0x2968c2d2eba0
val = 0x7f4fe52f5c83
ret = 0x0
#21 0x000055e7740c8e8c in Ffuncall (nargs=3, args=0x7ffd6a2b0f78) at ../../emacs/src/eval.c:3201
count = {bytes = <optimized out>}
val = <optimized out>
#22 0x00007f505b7c1d34 in F7265646973706c61792d2d7072652d7265646973706c61792d66756e6374696f6e73_redisplay__pre_redisplay_functions_0 ()
at /home/oscar/dev/emacs/igc/build/src/../native-lisp/31.0.50-3eae311e/preloaded/simple-fab5b0cf-fea6411a.eln
#23 0x000055e7740c8e8c in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7f505ad28040)
at ../../emacs/src/eval.c:3201
count = {bytes = <optimized out>}
val = <optimized out>
#24 0x000055e7740c7742 in Fapply (nargs=2, args=0x7f505ad28040) at ../../emacs/src/eval.c:2830
i = <optimized out>
funcall_nargs = <optimized out>
funcall_args = 0x0
spread_arg = <optimized out>
fun = 0x2968f6dc91d8
sa_avail = 16384
sa_count = {bytes = <optimized out>}
numargs = <optimized out>
retval = <optimized out>
#25 0x000055e77411753a in exec_byte_code
(fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
at ../../emacs/src/lisp.h:2306
call_nargs = 2
call_fun = <optimized out>
count1 = {bytes = <optimized out>}
val = <optimized out>
call_args = 0x7f505ad28040
original_fun = 0x43d0
op = 2
type = <optimized out>
targets = {0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e77411793f <exec_byte_code+2047>, 0x55e77411793a <exec_byte_code+2042>, 0x55e774117935 <exec_byte_code+2037>, 0x55e77411731d <exec_byte_code+477>, 0x55e77411731d <exec_byte_code+477>, 0x55e7741178f7 <exec_byte_code+1975>, 0x55e7741178b9 <exec_byte_code+1913>, 0x55e7741198e2 <exec_byte_code+10146>, 0x55e7741198dd <exec_byte_code+10141>, 0x55e7741198d8 <exec_byte_code+10136>, 0x55e7741198d3 <exec_byte_code+10131>, 0x55e774117357 <exec_byte_code+535>, 0x55e774117360 <exec_byte_code+544>, 0x55e7741198c6 <exec_byte_code+10118>, 0x55e7741198e7 <exec_byte_code+10151>, 0x55e77411976e <exec_byte_code+9774>, 0x55e774119769 <exec_byte_code+9769>, 0x55e774119764 <exec_byte_code+9764>, 0x55e77411975f <exec_byte_code+9759>, 0x55e7741172b9 <exec_byte_code+377>, 0x55e7741172c0 <exec_byte_code+384>, 0x55e774119745 <exec_byte_code+9733>, 0x55e774119752 <exec_byte_code+9746>, 0x55e7741196f3 <exec_byte_code+9651>, 0x55e7741196ee <exec_byte_code+9646>, 0x55e7741196e9 <exec_byte_code+9641>, 0x55e7741196e4 <exec_byte_code+9636>, 0x55e7741175ef <exec_byte_code+1199>, 0x55e7741175f0 <exec_byte_code+1200>, 0x55e774119705 <exec_byte_code+9669>, 0x55e7741196f8 <exec_byte_code+9656>, 0x55e7741196c5 <exec_byte_code+9605>, 0x55e7741196c0 <exec_byte_code+9600>, 0x55e7741196bb <exec_byte_code+9595>, 0x55e7741196b6 <exec_byte_code+9590>, 0x55e7741173bd <exec_byte_code+637>, 0x55e7741173c0 <exec_byte_code+640>, 0x55e7741196d7 <exec_byte_code+9623>, 0x55e7741196ca <exec_byte_code+9610>, 0x55e774119697 <exec_byte_code+9559>, 0x55e774119692 <exec_byte_code+9554>, 0x55e77411968d <exec_byte_code+9549>, 0x55e774119688 <exec_byte_code+9544>, 0x55e774117639 <exec_byte_code+1273>, 0x55e774117640 <exec_byte_code+1280>, 0x55e7741196a9 <exec_byte_code+9577>, 0x55e77411969c <exec_byte_code+9564>, 0x55e774119273 <exec_byte_code+8499>, 0x55e7741192a7 <exec_byte_code+8551>, 0x55e774119330 <exec_byte_code+8688>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e7741190c7 <exec_byte_code+8071>, 0x55e774119054 <exec_byte_code+7956>, 0x55e77411900d <exec_byte_code+7885>, 0x55e774118fc6 <exec_byte_code+7814>, 0x55e774118f81 <exec_byte_code+7745>, 0x55e7741197ef <exec_byte_code+9903>, 0x55e7741197af <exec_byte_code+9839>, 0x55e774118f4f <exec_byte_code+7695>, 0x55e77411984b <exec_byte_code+9995>, 0x55e774119773 <exec_byte_code+9779>, 0x55e774118f0f <exec_byte_code+7631>, 0x55e774118edf <exec_byte_code+7583>, 0x55e774118e9f <exec_byte_code+7519>, 0x55e774118e62 <exec_byte_code+7458>, 0x55e774118e21 <exec_byte_code+7393>, 0x55e774118dab <exec_byte_code+7275>, 0x55e774118d20 <exec_byte_code+7136>, 0x55e774118c8b <exec_byte_code+6987>, 0x55e774118c5b <exec_byte_code+6939>, 0x55e774118c2b <exec_byte_code+6891>, 0x55e774118beb <exec_byte_code+6827>, 0x55e774118bab <exec_byte_code+6763>, 0x55e774118b6b <exec_byte_code+6699>, 0x55e774118b27 <exec_byte_code+6631>, 0x55e774118aed <exec_byte_code+6573>, 0x55e774118ab3 <exec_byte_code+6515>, 0x55e774118a79 <exec_byte_code+6457>, 0x55e7741189d7 <exec_byte_code+6295>, 0x55e77411897b <exec_byte_code+6203>, 0x55e774118921 <exec_byte_code+6113>, 0x55e7741188c7 <exec_byte_code+6023>, 0x55e77411886d <exec_byte_code+5933>, 0x55e774118813 <exec_byte_code+5843>, 0x55e7741187b9 <exec_byte_code+5753>, 0x55e774118761 <exec_byte_code+5665>, 0x55e774118704 <exec_byte_code+5572>, 0x55e7741186ac <exec_byte_code+5484>, 0x55e774118654 <exec_byte_code+5396>, 0x55e7741185fc <exec_byte_code+5308>, 0x55e7741185a3 <exec_byte_code+5219>, 0x55e7741184b2 <exec_byte_code+4978>, 0x55e774117689 <exec_byte_code+1353>, 0x55e774118482 <exec_byte_code+4930>, 0x55e77411844d <exec_byte_code+4877>, 0x55e7741183bd <exec_byte_code+4733>, 0x55e774118373 <exec_byte_code+4659>, 0x55e774118343 <exec_byte_code+4611>, 0x55e774118311 <exec_byte_code+4561>, 0x55e7741182df <exec_byte_code+4511>, 0x55e7741182a5 <exec_byte_code+4453>, 0x55e774118273 <exec_byte_code+4403>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e774118241 <exec_byte_code+4353>, 0x55e77411820f <exec_byte_code+4303>, 0x55e7741181dd <exec_byte_code+4253>, 0x55e7741181ab <exec_byte_code+4203>, 0x55e774118179 <exec_byte_code+4153>, 0x55e774118149 <exec_byte_code+4105>, 0x55e774117689 <exec_byte_code+1353>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e774118105 <exec_byte_code+4037>, 0x55e7741180d4 <exec_byte_code+3988>, 0x55e7741180a3 <exec_byte_code+3939>, 0x55e774118062 <exec_byte_code+3874>, 0x55e774118021 <exec_byte_code+3809>, 0x55e774117ff0 <exec_byte_code+3760>, 0x55e774117fbf <exec_byte_code+3711>, 0x55e774117f7e <exec_byte_code+3646>, 0x55e774117f3d <exec_byte_code+3581>, 0x55e774117efc <exec_byte_code+3516>, 0x55e774117ec9 <exec_byte_code+3465>, 0x55e774117e98 <exec_byte_code+3416>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e77411943f <exec_byte_code+8959>, 0x55e774119615 <exec_byte_code+9429>, 0x55e774119887 <exec_byte_code+10055>, 0x55e7741195d6 <exec_byte_code+9366>, 0x55e77411959a <exec_byte_code+9306>, 0x55e77411955e <exec_byte_code+9246>, 0x55e77411949d <exec_byte_code+9053>, 0x55e774119478 <exec_byte_code+9016>, 0x55e774119712 <exec_byte_code+9682>, 0x55e77411941a <exec_byte_code+8922>, 0x55e7741193b7 <exec_byte_code+8823>, 0x55e774119382 <exec_byte_code+8770>, 0x55e77411933b <exec_byte_code+8699>, 0x55e77411921e <exec_byte_code+8414>, 0x55e7741191da <exec_byte_code+8346>, 0x55e774119190 <exec_byte_code+8272>, 0x55e774119125 <exec_byte_code+8165>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e774117e53 <exec_byte_code+3347>, 0x55e774117e22 <exec_byte_code+3298>, 0x55e774117df1 <exec_byte_code+3249>, 0x55e774117dc0 <exec_byte_code+3200>, 0x55e774117d8f <exec_byte_code+3151>, 0x55e774117d4e <exec_byte_code+3086>, 0x55e774117d0d <exec_byte_code+3021>, 0x55e774117ccc <exec_byte_code+2956>, 0x55e774117c8b <exec_byte_code+2891>, 0x55e774117c24 <exec_byte_code+2788>, 0x55e774117be3 <exec_byte_code+2723>, 0x55e774117ba2 <exec_byte_code+2658>, 0x55e774117b71 <exec_byte_code+2609>, 0x55e774117b25 <exec_byte_code+2533>, 0x55e774117ad9 <exec_byte_code+2457>, 0x55e774117a9b <exec_byte_code+2395>, 0x55e774117a5d <exec_byte_code+2333>, 0x55e774117a22 <exec_byte_code+2274>, 0x55e77411854b <exec_byte_code+5131>, 0x55e7741184fc <exec_byte_code+5052>, 0x55e7741179b2 <exec_byte_code+2162>, 0x55e774117944 <exec_byte_code+2052>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e774118ddb <exec_byte_code+7323>, 0x55e774118a33 <exec_byte_code+6387>, 0x55e774118407 <exec_byte_code+4807>, 0x55e774117873 <exec_byte_code+1843>, 0x55e77411782d <exec_byte_code+1773>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e7741177f4 <exec_byte_code+1716>, 0x55e774117790 <exec_byte_code+1616>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e774117756 <exec_byte_code+1558> <repeats 64 times>}
quitcounter = <optimized out>
bc = 0x55e7742cb858 <main_thread+312>
top = 0x7f505ad28038
pc = <optimized out>
bytestr = <optimized out>
vector = <optimized out>
maxdepth = <optimized out>
const_length = <optimized out>
bytestr_length = <optimized out>
vectorp = 0x7f506b0a53f0
max_stack = <optimized out>
frame_base = <optimized out>
fp = <optimized out>
bytestr_data = <optimized out>
rest = <optimized out>
mandatory = <optimized out>
nonrest = <optimized out>
pushedargs = <optimized out>
saved_quitcounter = 0 '\000'
saved_vectorp = 0xdd98
saved_bytestr_data = 0x7ffd00000002 <error: Cannot access memory at address 0x7ffd00000002>
result = <optimized out>
#26 0x000055e7740c8e8c in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7ffd6a2b1290)
at ../../emacs/src/eval.c:3201
count = {bytes = <optimized out>}
val = <optimized out>
#27 0x000055e7740c5dbe in internal_condition_case_n
(bfun=bfun <at> entry=0x55e7740c8d90 <Ffuncall>, nargs=nargs <at> entry=2, args=args <at> entry=0x7ffd6a2b1290, handlers=handlers <at> entry=0x38, hfun=hfun <at> entry=0x55e773f4e550 <dsafe_eval_handler>) at ../../emacs/src/eval.c:1793
val = <optimized out>
c = 0x55e77bd0b710
#28 0x000055e773f3bc04 in dsafe__call
(inhibit_quit=inhibit_quit <at> entry=true, f=0x55e7740c8d90 <Ffuncall>, nargs=nargs <at> entry=2, args=args <at> entry=0x7ffd6a2b1290) at ../../emacs/src/xdisp.c:3106
count = {bytes = <optimized out>}
redisplay_counter_before = 939536
val = <optimized out>
#29 0x000055e773f6efbe in dsafe__call (inhibit_quit=true, nargs=2, f=<optimized out>, args=0x7ffd6a2b1290)
at ../../emacs/src/xdisp.c:3094
val = <optimized out>
count = {bytes = <optimized out>}
redisplay_counter_before = <optimized out>
#30 prepare_menu_bars () at ../../emacs/src/xdisp.c:14060
windows = <optimized out>
all_windows = <optimized out>
some_windows = <optimized out>
all_windows = <optimized out>
some_windows = <optimized out>
windows = <optimized out>
ws = <optimized out>
this = <optimized out>
w = <optimized out>
tail = <optimized out>
frame = <optimized out>
f = <optimized out>
w = <optimized out>
tail = <optimized out>
frame = <optimized out>
count = {bytes = <optimized out>}
menu_bar_hooks_run = <optimized out>
sw = <optimized out>
sf = <optimized out>
rf = <optimized out>
f = <optimized out>
w = <optimized out>
sw = <optimized out>
sf = <optimized out>
rf = <optimized out>
#31 redisplay_internal () at ../../emacs/src/xdisp.c:17289
w = 0x7f50663eea30
sw = 0x7f50663eea30
fr = <optimized out>
must_finish = <optimized out>
match_p = <optimized out>
tlbufpos = {charpos = <optimized out>, bytepos = <optimized out>}
tlendpos = {charpos = <optimized out>, bytepos = <optimized out>}
number_of_visible_frames = <optimized out>
sf = <optimized out>
polling_stopped_here = <optimized out>
tail = <optimized out>
frame = <optimized out>
hscroll_retries = <optimized out>
garbaged_frame_retries = <optimized out>
consider_all_windows_p = <optimized out>
update_miniwindow_p = <optimized out>
count = {bytes = <optimized out>}
retry = <optimized out>
previous_frame = <optimized out>
current_matrices_cleared = <optimized out>
new_count = <optimized out>
#32 0x000055e773f70ee5 in redisplay_preserve_echo_area (from_where=from_where <at> entry=8)
at ../../emacs/src/xdisp.c:18050
count = {bytes = <optimized out>}
#33 0x000055e77404e811 in detect_input_pending_run_timers (do_display=do_display <at> entry=true)
at ../../emacs/src/keyboard.c:11765
old_timers_run = <optimized out>
#34 0x000055e77412e143 in wait_reading_process_output
(time_limit=time_limit <at> entry=30, nsecs=nsecs <at> entry=0, read_kbd=read_kbd <at> entry=-1, do_display=do_display <at> entry=true, wait_for_cell=wait_for_cell <at> entry=0x0, wait_proc=wait_proc <at> entry=0x0, just_wait_proc=0)
at ../../emacs/src/process.c:5863
leave = false
process_skipped = <optimized out>
wrapped = <optimized out>
channel_start = <optimized out>
child_fd = <optimized out>
last_read_channel = 18
channel = <optimized out>
nfds = <optimized out>
Available = {fds_bits = {103483688, 0 <repeats 15 times>}}
Writeok = {fds_bits = {0 <repeats 16 times>}}
check_write = <optimized out>
check_delay = <optimized out>
no_avail = false
xerrno = 11
proc = <optimized out>
timeout = {tv_sec = 0, tv_nsec = 39276532}
end_time = {tv_sec = <optimized out>, tv_nsec = <optimized out>}
timer_delay = {tv_sec = <optimized out>, tv_nsec = <optimized out>}
got_output_end_time = {tv_sec = <optimized out>, tv_nsec = <optimized out>}
wait = <optimized out>
got_some_output = -1
prev_wait_proc_nbytes_read = 0
retry_for_async = <optimized out>
count = {bytes = <optimized out>}
now = {tv_sec = <optimized out>, tv_nsec = <optimized out>}
#35 0x000055e773f28d48 in sit_for
(timeout=timeout <at> entry=0x7a, reading=reading <at> entry=true, display_option=display_option <at> entry=1)
at ../../emacs/src/dispnew.c:7007
sec = 30
nsec = 0
do_display = true
curbuf_eq_winbuf = true
nbytes = <optimized out>
#36 0x000055e774049751 in read_char
(commandflag=1, map=map <at> entry=0x7f4fe3bb2743, prev_event=0x0, used_mouse_menu=used_mouse_menu <at> entry=0x7ffd6a2b2f8b, end_time=end_time <at> entry=0x0) at ../../emacs/src/keyboard.c:2942
tem0 = <optimized out>
timeout = 30
count1 = {bytes = <optimized out>}
delay_level = <optimized out>
buffer_size = <optimized out>
c = <optimized out>
local_getcjmp = {{__jmpbuf = {139983216267777, -7185469048144634495, 94452706735984, 0, 5961, 139981099837251, -7185469048002028159, -4000276575438611071}, __mask_was_saved = 0, __saved_mask = {__val = {128, 0, 0, 139981142478776, 94452574418320, 140726384668096, 94452572778276, 139982496915949, 139981099825088, 139983273579872, 139983297782696, 140726384668064, 94452572696013, 140726384668096, 45530698062208, 140726384668208}}}}
save_jump = {{__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = {__val = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 94452572778135, 0, 0, 3, 94452572190992, 140726384659360}}}}
tem = <optimized out>
save = <optimized out>
previous_echo_area_message = 0x0
also_record = 0x0
reread = false
recorded = false
polling_stopped_here = false
orig_kboard = 0x55e77c087770
retry = <optimized out>
jmpcount = {bytes = <optimized out>}
c_volatile = 0x0
#37 0x000055e77404ab21 in read_key_sequence
(keybuf=keybuf <at> entry=0x7ffd6a2b30c0, prompt=prompt <at> entry=0x0, dont_downcase_last=dont_downcase_last <at> entry=false, can_return_switch_frame=can_return_switch_frame <at> entry=true, fix_current_buffer=fix_current_buffer <at> entry=true, prevent_redisplay=prevent_redisplay <at> entry=false, disable_text_conversion_p=false)
at ../../emacs/src/keyboard.c:10932
interrupted_kboard = 0x55e77c087770
interrupted_frame = <optimized out>
key = <optimized out>
used_mouse_menu = false
echo_local_start = 0
last_real_key_start = <optimized out>
keys_local_start = 0
new_binding = <optimized out>
count = {bytes = <optimized out>}
t = <optimized out>
echo_start = 0
keys_start = 0
current_binding = 0x7f4fe3bb2743
first_unbound = 31
mock_input = <optimized out>
used_mouse_menu_history = {false <repeats 30 times>}
fkey = {parent = 0x7f506743f903, map = 0x7f506743f903, start = 0, end = 0}
keytran = {parent = 0x7f5064402d0b, map = 0x7f5064402d0b, start = 0, end = 0}
indec = {parent = 0x7f506743f8eb, map = 0x7f506743f8eb, start = 0, end = 0}
shift_translated = <optimized out>
delayed_switch_frame = <optimized out>
original_uppercase = <optimized out>
original_uppercase_position = <optimized out>
disabled_conversion = <optimized out>
starting_buffer = <optimized out>
fake_prefixed_keys = 0x0
first_event = 0x0
second_event = <optimized out>
#38 0x000055e77404c8a8 in command_loop_1 () at ../../emacs/src/keyboard.c:1441
cmd = <optimized out>
keybuf = {0x1e2, 0x18a, 0x1de, 0x0, 0xffffffffffffffff, 0x55e774257590, 0x7ffd6a2b3160, 0x55e7740c6f24 <unbind_to+308>, 0x7f4fe2d1ca2b, 0x7ffd6a2b3180, 0xc, 0x13cf8, 0x38, 0x7f4fe15cf0b5, 0x2968f69e5cc8, 0x7f4fe2d1ca2b, 0x60, 0x7ffd6a2b3180, 0xffffffffffffffff, 0x7ffd6a2b3338, 0x7ffd6a2b31e0, 0x55e77403facd <cmd_error+349>, 0x0, 0x0, 0xffffffffffffff00, 0x55e774257590, 0x7ffd6a2b3200, 0x55e7740c6f24 <unbind_to+308>, 0x0, 0xcd68}
i = <optimized out>
last_pt = <optimized out>
prev_modiff = 52791
prev_buffer = 0x7f4fe645cfb8
#39 0x000055e7740c5c36 in internal_condition_case
(bfun=bfun <at> entry=0x55e77404c6f0 <command_loop_1>, handlers=handlers <at> entry=0xa8, hfun=hfun <at> entry=0x55e77403f970 <cmd_error>) at ../../emacs/src/eval.c:1713
val = <optimized out>
c = 0x55e77bd0b580
#40 0x000055e77403758e in command_loop_2 (handlers=handlers <at> entry=0xa8) at ../../emacs/src/keyboard.c:1180
val = <optimized out>
#41 0x000055e7740c5b62 in internal_catch
(tag=tag <at> entry=0x15118, func=func <at> entry=0x55e774037560 <command_loop_2>, arg=arg <at> entry=0xa8)
at ../../emacs/src/eval.c:1393
val = <optimized out>
c = <optimized out>
#42 0x000055e774037523 in command_loop () at ../../emacs/src/keyboard.c:1158
#43 0x000055e77403f4e6 in recursive_edit_1 () at ../../emacs/src/keyboard.c:766
count = {bytes = <optimized out>}
val = <optimized out>
#44 0x000055e77403f898 in Frecursive_edit () at ../../emacs/src/keyboard.c:849
count = {bytes = <optimized out>}
buffer = <optimized out>
#45 0x000055e773f1c415 in main (argc=<optimized out>, argv=0x7ffd6a2b3558) at ../../emacs/src/emacs.c:2651
stack_bottom_variable = 0x55e77bbd1b60
old_argc = <optimized out>
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = <optimized out>
dump_mode = <optimized out>
skip_args = 1
temacs = 0x0
attempt_load_pdump = <optimized out>
only_version = false
rlim = {rlim_cur = 10022912, rlim_max = 18446744073709551615}
lc_all = <optimized out>
sockfd = -1
module_assertions = <optimized out>
(gdb)
In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.18.4) of 2025-07-27 built on zen
Repository revision: 3ea927a0ff6d3050c7df6858e386ef7da3d7e690
Repository branch: feature/igc
Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
System Description: Debian GNU/Linux 13 (trixie)
Configured using:
'configure 'CPPFLAGS=-O2 -fno-omit-frame-pointer -g3'
CPPFLAGS=-I/home/oscar/dev/include/mps
LDFLAGS=-L/home/oscar/dev/other/mps/code --with-native-compilation
--with-tree-sitter --without-toolkit-scroll-bars --with-x-toolkit=lucid
--with-modules --without-imagemagick --with-mps=yes'
Configured features:
CAIRO FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBOTF
LIBSELINUX LIBXML2 MODULES MPS NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG
RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TREE_SITTER WEBP X11 XAW3D XDBE
XIM XPM LUCID ZLIB
Important settings:
value of $LANG: C
locale-coding-system: nil
Major mode: lp0[ts]
Minor modes in effect:
ofv-time-tracker-mode: t
window-highlight-mode: t
treemacs-filewatch-mode: t
treemacs-follow-mode: t
treemacs-git-mode: t
treemacs-fringe-indicator-mode: t
flycheck-mode: t
symbol-overlay-mode: t
company-fuzzy-mode: t
company-mode: t
aggressive-indent-mode: t
org-roam-db-autosync-mode: t
fancy-compilation-mode: t
diff-hl-flydiff-mode: t
diff-hl-mode: t
difftastic-bindings-mode: t
global-git-commit-mode: t
pulsar-global-mode: t
pulsar-mode: t
evil-owl-mode: t
enhanced-evil-paredit-mode: t
evil-local-mode: t
mini-echo-mode: t
global-hide-mode-line-mode: t
hide-mode-line-mode: t
key-chord-mode: t
paredit-mode: t
server-mode: t
yas-minor-mode: t
display-fill-column-indicator-mode: t
vertico-multiform-mode: t
marginalia-mode: t
vertico-mode: t
ws-butler-mode: t
which-key-mode: t
global-anzu-mode: t
anzu-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
window-divider-mode: t
minibuffer-regexp-mode: t
column-number-mode: t
line-number-mode: t
indent-tabs-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
/home/oscar/elisp/singles/flx hides /home/oscar/.emacs.d/elpa/flx-20240205.356/flx
/home/oscar/elisp/magit/lisp/magit-section hides /home/oscar/.emacs.d/elpa/magit-section-20250725.1036/magit-section
/home/oscar/elisp/singles/which-key hides /home/oscar/dev/emacs/igc/emacs/lisp/which-key
Features:
(shadow sort mail-extr emacsbug vc-hg vc-bzr vc-src vc-sccs vc-cvs
vc-rcs bug-reference consult dabbrev misearch multi-isearch whitespace
company-dabbrev-code company-dabbrev ofv-time-tracker cus-start cus-load
help-fns radix-tree vertico-grid mm-archive gnutls url-cache url-http
url-auth url-gw display-line-numbers vertico-directory mule-util
vertico-sort fussy window-highlight solarized-selenized-dark-theme
solarized-selenized-light-theme solarized-palettes solarized
solarized-faces meteo-radar lsp-dart lsp-dart-commands
lsp-dart-flutter-widget-guide lsp-dart-flutter-fringe-colors
lsp-dart-flutter-colors lsp-dart-outline lsp-dart-code-lens lsp-lens
lsp-dart-test-tree lsp-treemacs lsp-treemacs-generic lsp-treemacs-themes
treemacs-treelib treemacs treemacs-header-line treemacs-compatibility
treemacs-mode treemacs-bookmarks treemacs-tags treemacs-interface
treemacs-persistence treemacs-filewatch-mode treemacs-follow-mode
treemacs-rendering treemacs-annotations treemacs-async
treemacs-workspaces treemacs-dom treemacs-visuals
treemacs-fringe-indicator treemacs-faces treemacs-icons treemacs-scope
treemacs-themes treemacs-core-utils pfuture hl-line treemacs-logging
treemacs-customization treemacs-macros lsp-dart-test-output
lsp-dart-test-support lsp-dart-dap lsp-dart-devtools
lsp-dart-flutter-daemon jsonrpc dap-utils dom xml dap-mode dap-tasks
dap-launch lsp-docker yaml posframe dap-overlays lsp-dart-closing-labels
lsp-dart-utils lsp-dart-protocol lsp-mode lsp-protocol tree-widget
spinner network-stream nsm markdown-mode lv f flymake flycheck
lp0-ts-mode lp0-mode symbol-overlay company-ctags find-file
company-fuzzy ht company aggressive-indent deft orgit
emacsql-sqlite-builtin org-roam-migrate org-roam-log org-roam-mode
org-roam-capture org-roam-id org-roam-node org-roam-db org-roam-utils
org-roam-compat org-roam org-attach emacsql-sqlite emacsql
emacsql-compiler org-noter org-element org-persist org-id
org-element-ast inline avl-tree org-protocol org-capture org-refile
org-crypt org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro
org-src sh-script smie treesit executable ob-comint org-pcomplete
org-list org-footnote org-faces org-entities noutline outline
ob-emacs-lisp ob-core ob-eval org-cycle org-table org-keys oc
org-loaddefs find-func etags-select etags fileloop generator xref
project ol org-fold org-fold-core org-compat org-version org-macs
cond-star fancy-compilation ffap diff-hl-flydiff diff-hl log-view vc-dir
ewoc vc difftastic-bindings difftastic view magit-bookmark bookmark
git-rebase magit-dired magit-extras magit-sparse-checkout
magit-gitignore magit-ediff ediff magit-subtree magit-patch
magit-submodule magit-blame magit-stash magit-reflog magit-bisect
magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit
magit-sequence magit-notes magit-worktree magit-tag magit-merge
magit-branch magit-reset magit-files magit-refs magit-status magit
magit-repos magit-apply magit-wip magit-log magit-diff smerge-mode diff
git-commit magit-core magit-autorevert autorevert filenotify
magit-margin magit-transient magit-process with-editor shell pcomplete
magit-mode transient magit-git magit-base which-func imenu vc-git
files-x vc-dispatcher magit-section benchmark cursor-sensor crm llama
pulsar pulse color evil-owl format-spec buffer-flip
enhanced-evil-paredit evil-anzu evil evil-keybindings evil-integration
evil-maps evil-commands evil-digraphs reveal evil-jumps
evil-command-window evil-types evil-search evil-ex evil-macros
evil-repeat evil-states evil-core evil-common rect evil-vars mini-echo
mini-echo-segments let-alist hide-mode-line face-remap wgrep grep ag
vc-svn find-dired s dash key-chord comp comp-cstr comp-run comp-common
cmake-mode rx rst compile comint ansi-osc ansi-color paredit-menu
paredit edmacro kmacro server yasnippet lisp-mnt psvn wid-edit log-edit
message sendmail yank-media puny rfc822 mml mml-sec epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader
pcvs-util add-log diff-mode track-changes pp elp ediff-merg ediff-mult
ediff-wind ediff-diff ediff-help ediff-init ediff-util dired
dired-loaddefs display-fill-column-indicator vertico-multiform
marginalia vertico flx-rs-core flx-rs flx goto-chg avy ring
highlight-parentheses ws-butler which-key diminish cl anzu easy-mmode
thingatpt tmr pcase compat solar cal-dst cal-menu calendar cal-loaddefs
finder-inf advice cl-extra help-mode warnings disp-table
apropospriate-theme-autoloads company-posframe-autoloads
company-autoloads consult-flycheck-autoloads consult-lsp-autoloads
consult-org-roam-autoloads corfu-autoloads deadgrep-autoloads
diff-hl-autoloads eat-autoloads ellama-autoloads
embark-consult-autoloads consult-autoloads embark-autoloads
flutter-autoloads flycheck-autoloads fussy-autoloads flx-autoloads
groovy-mode-autoloads llm-autoloads lsp-dart-autoloads
dart-mode-autoloads dap-mode-autoloads bui-autoloads
lsp-docker-autoloads lsp-treemacs-autoloads lsp-ui-autoloads
lsp-mode-autoloads f-autoloads marginalia-autoloads
markdown-mode-autoloads org-roam-autoloads magit-section-autoloads
llama-autoloads emacsql-autoloads plz-event-source-autoloads
plz-media-type-autoloads plz-autoloads pomm-autoloads alert-autoloads
log4e-autoloads gntp-autoloads spinner-autoloads swiper-autoloads
ivy-autoloads symbol-overlay-autoloads treemacs-autoloads cfrs-autoloads
posframe-autoloads ht-autoloads hydra-autoloads lv-autoloads
pfuture-autoloads ace-window-autoloads avy-autoloads s-autoloads info
dash-autoloads vertico-autoloads wgrep-ag-autoloads
wgrep-deadgrep-autoloads wgrep-autoloads yaml-autoloads package
browse-url xdg url url-proxy url-privacy url-expand url-methods
url-history url-cookie generate-lisp-file url-domsuf url-util mailcap
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs icons
password-cache json subr-x map byte-opt gv bytecomp byte-compile
url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd fontset
image regexp-opt fringe tabulated-list replace newcomment text-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads inotify dynamic-setting
system-font-setting font-render-setting cairo x-toolkit x multi-tty
move-toolbar make-network-process tty-child-frames native-compile mps
emacs)
Memory information:
((conses 24 0 0) (symbols 56 0 0) (strings 40 0 0) (string-bytes 1 0)
(vectors 24 0) (vector-slots 8 0 0) (floats 24 0 0)
(intervals 64 0 0) (buffers 1072 0))
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Thu, 31 Jul 2025 05:12:02 GMT) Full text and rfc822 format available.Message #8 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Óscar Fuentes <oscarfv <at> eclipso.eu>, Yuan Fu <casouri <at> gmail.com> Cc: gerd.moellmann <at> gmail.com, 79131 <at> debbugs.gnu.org, pipcet <at> protonmail.com Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Thu, 31 Jul 2025 08:11:00 +0300
> Cc: Pip Cet <pipcet <at> protonmail.com>,
> Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Wed, 30 Jul 2025 22:18:44 +0200
> From: Óscar Fuentes via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
>
> This is a build of merging master's 6982dc460aa with current feature/igc
> HEAD (382123e69e2). I had to resolve some conflicts, so there is a
> possibility of the crash being caused by my mistake.
>
> Backtrace from the coredump:
>
> (gdb) bt full
> #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo <at> entry=11, no_tid=no_tid <at> entry=0)
> at ./nptl/pthread_kill.c:44
> tid = <optimized out>
> ret = 0
> pd = <optimized out>
> old_mask = {__val = {94452575465120}}
> ret = <optimized out>
> #1 0x00007f506ce9e9ff in __pthread_kill_internal (threadid=<optimized out>, signo=11)
> at ./nptl/pthread_kill.c:89
> #2 0x00007f506ce49cc2 in __GI_raise (sig=sig <at> entry=11) at ../sysdeps/posix/raise.c:26
> ret = <optimized out>
> #3 0x000055e773f12db8 in terminate_due_to_signal
> (sig=sig <at> entry=11, backtrace_limit=backtrace_limit <at> entry=40) at ../../emacs/src/emacs.c:481
> #4 0x000055e773f132de in handle_fatal_signal (sig=sig <at> entry=11) at ../../emacs/src/sysdep.c:1793
> #5 0x000055e773f132e5 in deliver_thread_signal
> (sig=sig <at> entry=11, handler=0x55e773f132d0 <handle_fatal_signal>) at ../../emacs/src/sysdep.c:1785
> old_errno = <optimized out>
> #6 0x000055e774058dec in deliver_fatal_thread_signal (sig=11) at ../../emacs/src/sysdep.c:1805
> #7 handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at ../../emacs/src/sysdep.c:1943
> fatal = <optimized out>
> #8 0x00007f506ce49df0 in <signal handler called> () at /lib/x86_64-linux-gnu/libc.so.6
> #9 0x00007f506ce4a007 in __GI_kill () at ../sysdeps/unix/syscall-template.S:120
> #10 0x000055e774215e44 in sigHandle ()
> #11 0x00007f506ce49df0 in <signal handler called> () at /lib/x86_64-linux-gnu/libc.so.6
> #12 add_text_properties_1 (start=<optimized out>, start <at> entry=0x1f06a, end=<optimized out>,
> end <at> entry=0x1f07a, properties=0x7f4fe3c2acc3, object=0x7f4fe645cfbd,
> object <at> entry=0x0, set_type=set_type <at> entry=TEXT_PROPERTY_REPLACE, destructive=destructive <at> entry=true)
> --Type <RET> for more, q to quit, c to continue without paging--c
> at ../../emacs/src/textprop.c:1252
> i = 0x0
> unchanged = <optimized out>
> s = 31770
> len = 3
> modified = <optimized out>
> first_time = <optimized out>
Since this in code that is the result of your local merge, please be
sure to show the source lines corresponding to the call-stack frames
where the signal was raised. Otherwise, we are left guessing what is
line 1252 in your version of textprop.c that could trigger SIGSEGV.
My guess is that it's here:
/* We are at the beginning of interval I, with LEN chars to scan. */
for (;;)
{
eassert (i != 0);
if (LENGTH (i) >= len) <<<<<<<<<<<<<<<<
but I shouldn't be guessing. If my guess is correct, this is some
snafu with intervals in the buffer that happens to be the current one.
> #13 0x000055e77414774b in Fadd_text_properties
> (start=0x1f06a, end=0x1f07a, properties=<optimized out>, object=0x0) at ../../emacs/src/textprop.c:1308
> #14 Fput_text_property
> (start=0x1f06a, end=0x1f07a, property=<optimized out>, value=<optimized out>, object=0x0)
> at ../../emacs/src/textprop.c:1326
> properties = <optimized out>
> #15 0x00007f505801aec2 in F747265657369742d2d666f6e742d6c6f636b2d6d61726b2d72616e6765732d746f2d666f6e74696679_treesit__font_lock_mark_ranges_to_fontify_0 ()
> at /home/oscar/.emacs.d/eln-cache/31.0.50-3eae311e/treesit-37439c61-2c208e3a.eln
> #16 0x000055e7740c8e8c in Ffuncall (nargs=2, args=0x7ffd6a2b0e70) at ../../emacs/src/eval.c:3201
> count = {bytes = <optimized out>}
> val = <optimized out>
> #17 0x00007f505801b396 in F747265657369742d2d7072652d7265646973706c6179_treesit__pre_redisplay_0 ()
> at /home/oscar/.emacs.d/eln-cache/31.0.50-3eae311e/treesit-37439c61-2c208e3a.eln
> #18 0x000055e7740c8e8c in Ffuncall (nargs=2, args=0x7ffd6a2b0f80) at ../../emacs/src/eval.c:3201
> count = {bytes = <optimized out>}
> val = <optimized out>
> #19 0x000055e7740c90e9 in funcall_nil (nargs=<optimized out>, args=<optimized out>)
> at ../../emacs/src/eval.c:2884
> #20 0x000055e7740c643d in run_hook_with_args
> (nargs=2, args=0x7ffd6a2b0f80, funcall=0x55e7740c90e0 <funcall_nil>) at ../../emacs/src/eval.c:3061
> global_vals = <optimized out>
> sym = 0x2968c2d2eba0
> val = 0x7f4fe52f5c83
> ret = 0x0
> #21 0x000055e7740c8e8c in Ffuncall (nargs=3, args=0x7ffd6a2b0f78) at ../../emacs/src/eval.c:3201
> count = {bytes = <optimized out>}
> val = <optimized out>
> #22 0x00007f505b7c1d34 in F7265646973706c61792d2d7072652d7265646973706c61792d66756e6374696f6e73_redisplay__pre_redisplay_functions_0 ()
> at /home/oscar/dev/emacs/igc/build/src/../native-lisp/31.0.50-3eae311e/preloaded/simple-fab5b0cf-fea6411a.eln
> #23 0x000055e7740c8e8c in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7f505ad28040)
> at ../../emacs/src/eval.c:3201
> count = {bytes = <optimized out>}
> val = <optimized out>
> #24 0x000055e7740c7742 in Fapply (nargs=2, args=0x7f505ad28040) at ../../emacs/src/eval.c:2830
> i = <optimized out>
> funcall_nargs = <optimized out>
> funcall_args = 0x0
> spread_arg = <optimized out>
> fun = 0x2968f6dc91d8
> sa_avail = 16384
> sa_count = {bytes = <optimized out>}
> numargs = <optimized out>
> retval = <optimized out>
> #25 0x000055e77411753a in exec_byte_code
> (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
> at ../../emacs/src/lisp.h:2306
> call_nargs = 2
> call_fun = <optimized out>
> count1 = {bytes = <optimized out>}
> val = <optimized out>
> call_args = 0x7f505ad28040
> original_fun = 0x43d0
> op = 2
> type = <optimized out>
> targets = {0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e77411793f <exec_byte_code+2047>, 0x55e77411793a <exec_byte_code+2042>, 0x55e774117935 <exec_byte_code+2037>, 0x55e77411731d <exec_byte_code+477>, 0x55e77411731d <exec_byte_code+477>, 0x55e7741178f7 <exec_byte_code+1975>, 0x55e7741178b9 <exec_byte_code+1913>, 0x55e7741198e2 <exec_byte_code+10146>, 0x55e7741198dd <exec_byte_code+10141>, 0x55e7741198d8 <exec_byte_code+10136>, 0x55e7741198d3 <exec_byte_code+10131>, 0x55e774117357 <exec_byte_code+535>, 0x55e774117360 <exec_byte_code+544>, 0x55e7741198c6 <exec_byte_code+10118>, 0x55e7741198e7 <exec_byte_code+10151>, 0x55e77411976e <exec_byte_code+9774>, 0x55e774119769 <exec_byte_code+9769>, 0x55e774119764 <exec_byte_code+9764>, 0x55e77411975f <exec_byte_code+9759>, 0x55e7741172b9 <exec_byte_code+377>, 0x55e7741172c0 <exec_byte_code+384>, 0x55e774119745 <exec_byte_code+9733>, 0x55e774119752 <exec_byte_code+9746>, 0x55e7741196f3 <exec_byte_code+9651>, 0x55e7741196ee <exec_byte_code+9646>, 0x55e7741196e9 <exec_byte_code+9641>, 0x55e7741196e4 <exec_byte_code+9636>, 0x55e7741175ef <exec_byte_code+1199>, 0x55e7741175f0 <exec_byte_code+1200>, 0x55e774119705 <exec_byte_code+9669>, 0x55e7741196f8 <exec_byte_code+9656>, 0x55e7741196c5 <exec_byte_code+9605>, 0x55e7741196c0 <exec_byte_code+9600>, 0x55e7741196bb <exec_byte_code+9595>, 0x55e7741196b6 <exec_byte_code+9590>, 0x55e7741173bd <exec_byte_code+637>, 0x55e7741173c0 <exec_byte_code+640>, 0x55e7741196d7 <exec_byte_code+9623>, 0x55e7741196ca <exec_byte_code+9610>, 0x55e774119697 <exec_byte_code+9559>, 0x55e774119692 <exec_byte_code+9554>, 0x55e77411968d <exec_byte_code+9549>, 0x55e774119688 <exec_byte_code+9544>, 0x55e774117639 <exec_byte_code+1273>, 0x55e774117640 <exec_byte_code+1280>, 0x55e7741196a9 <exec_byte_code+9577>, 0x55e77411969c <exec_byte_code+9564>, 0x55e774119273 <exec_byte_code+8499>, 0x55e7741192a7 <exec_byte_code+8551>, 0x55e774119330 <exec_byte_code+8688>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e7741190c7 <exec_byte_code+8071>, 0x55e774119054 <exec_byte_code+7956>, 0x55e77411900d <exec_byte_code+7885>, 0x55e774118fc6 <exec_byte_code+7814>, 0x55e774118f81 <exec_byte_code+7745>, 0x55e7741197ef <exec_byte_code+9903>, 0x55e7741197af <exec_byte_code+9839>, 0x55e774118f4f <exec_byte_code+7695>, 0x55e77411984b <exec_byte_code+9995>, 0x55e774119773 <exec_byte_code+9779>, 0x55e774118f0f <exec_byte_code+7631>, 0x55e774118edf <exec_byte_code+7583>, 0x55e774118e9f <exec_byte_code+7519>, 0x55e774118e62 <exec_byte_code+7458>, 0x55e774118e21 <exec_byte_code+7393>, 0x55e774118dab <exec_byte_code+7275>, 0x55e774118d20 <exec_byte_code+7136>, 0x55e774118c8b <exec_byte_code+6987>, 0x55e774118c5b <exec_byte_code+6939>, 0x55e774118c2b <exec_byte_code+6891>, 0x55e774118beb <exec_byte_code+6827>, 0x55e774118bab <exec_byte_code+6763>, 0x55e774118b6b <exec_byte_code+6699>, 0x55e774118b27 <exec_byte_code+6631>, 0x55e774118aed <exec_byte_code+6573>, 0x55e774118ab3 <exec_byte_code+6515>, 0x55e774118a79 <exec_byte_code+6457>, 0x55e7741189d7 <exec_byte_code+6295>, 0x55e77411897b <exec_byte_code+6203>, 0x55e774118921 <exec_byte_code+6113>, 0x55e7741188c7 <exec_byte_code+6023>, 0x55e77411886d <exec_byte_code+5933>, 0x55e774118813 <exec_byte_code+5843>, 0x55e7741187b9 <exec_byte_code+5753>, 0x55e774118761 <exec_byte_code+5665>, 0x55e774118704 <exec_byte_code+5572>, 0x55e7741186ac <exec_byte_code+5484>, 0x55e774118654 <exec_byte_code+5396>, 0x55e7741185fc <exec_byte_code+5308>, 0x55e7741185a3 <exec_byte_code+5219>, 0x55e7741184b2 <exec_byte_code+4978>, 0x55e774117689 <exec_byte_code+1353>, 0x55e774118482 <exec_byte_code+4930>, 0x55e77411844d <exec_byte_code+4877>, 0x55e7741183bd <exec_byte_code+4733>, 0x55e774118373 <exec_byte_code+4659>, 0x55e774118343 <exec_byte_code+4611>, 0x55e774118311 <exec_byte_code+4561>, 0x55e7741182df <exec_byte_code+4511>, 0x55e7741182a5 <exec_byte_code+4453>, 0x55e774118273 <exec_byte_code+4403>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e774118241 <exec_byte_code+4353>, 0x55e77411820f <exec_byte_code+4303>, 0x55e7741181dd <exec_byte_code+4253>, 0x55e7741181ab <exec_byte_code+4203>, 0x55e774118179 <exec_byte_code+4153>, 0x55e774118149 <exec_byte_code+4105>, 0x55e774117689 <exec_byte_code+1353>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e774118105 <exec_byte_code+4037>, 0x55e7741180d4 <exec_byte_code+3988>, 0x55e7741180a3 <exec_byte_code+3939>, 0x55e774118062 <exec_byte_code+3874>, 0x55e774118021 <exec_byte_code+3809>, 0x55e774117ff0 <exec_byte_code+3760>, 0x55e774117fbf <exec_byte_code+3711>, 0x55e774117f7e <exec_byte_code+3646>, 0x55e774117f3d <exec_byte_code+3581>, 0x55e774117efc <exec_byte_code+3516>, 0x55e774117ec9 <exec_byte_code+3465>, 0x55e774117e98 <exec_byte_code+3416>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e77411943f <exec_byte_code+8959>, 0x55e774119615 <exec_byte_code+9429>, 0x55e774119887 <exec_byte_code+10055>, 0x55e7741195d6 <exec_byte_code+9366>, 0x55e77411959a <exec_byte_code+9306>, 0x55e77411955e <exec_byte_code+9246>, 0x55e77411949d <exec_byte_code+9053>, 0x55e774119478 <exec_byte_code+9016>, 0x55e774119712 <exec_byte_code+9682>, 0x55e77411941a <exec_byte_code+8922>, 0x55e7741193b7 <exec_byte_code+8823>, 0x55e774119382 <exec_byte_code+8770>, 0x55e77411933b <exec_byte_code+8699>, 0x55e77411921e <exec_byte_code+8414>, 0x55e7741191da <exec_byte_code+8346>, 0x55e774119190 <exec_byte_code+8272>, 0x55e774119125 <exec_byte_code+8165>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e774117e53 <exec_byte_code+3347>, 0x55e774117e22 <exec_byte_code+3298>, 0x55e774117df1 <exec_byte_code+3249>, 0x55e774117dc0 <exec_byte_code+3200>, 0x55e774117d8f <exec_byte_code+3151>, 0x55e774117d4e <exec_byte_code+3086>, 0x55e774117d0d <exec_byte_code+3021>, 0x55e774117ccc <exec_byte_code+2956>, 0x55e774117c8b <exec_byte_code+2891>, 0x55e774117c24 <exec_byte_code+2788>, 0x55e774117be3 <exec_byte_code+2723>, 0x55e774117ba2 <exec_byte_code+2658>, 0x55e774117b71 <exec_byte_code+2609>, 0x55e774117b25 <exec_byte_code+2533>, 0x55e774117ad9 <exec_byte_code+2457>, 0x55e774117a9b <exec_byte_code+2395>, 0x55e774117a5d <exec_byte_code+2333>, 0x55e774117a22 <exec_byte_code+2274>, 0x55e77411854b <exec_byte_code+5131>, 0x55e7741184fc <exec_byte_code+5052>, 0x55e7741179b2 <exec_byte_code+2162>, 0x55e774117944 <exec_byte_code+2052>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e774118ddb <exec_byte_code+7323>, 0x55e774118a33 <exec_byte_code+6387>, 0x55e774118407 <exec_byte_code+4807>, 0x55e774117873 <exec_byte_code+1843>, 0x55e77411782d <exec_byte_code+1773>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e7741177f4 <exec_byte_code+1716>, 0x55e774117790 <exec_byte_code+1616>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e774117756 <exec_byte_code+1558> <repeats 64 times>}
> quitcounter = <optimized out>
> bc = 0x55e7742cb858 <main_thread+312>
> top = 0x7f505ad28038
> pc = <optimized out>
> bytestr = <optimized out>
> vector = <optimized out>
> maxdepth = <optimized out>
> const_length = <optimized out>
> bytestr_length = <optimized out>
> vectorp = 0x7f506b0a53f0
> max_stack = <optimized out>
> frame_base = <optimized out>
> fp = <optimized out>
> bytestr_data = <optimized out>
> rest = <optimized out>
> mandatory = <optimized out>
> nonrest = <optimized out>
> pushedargs = <optimized out>
> saved_quitcounter = 0 '\000'
> saved_vectorp = 0xdd98
> saved_bytestr_data = 0x7ffd00000002 <error: Cannot access memory at address 0x7ffd00000002>
> result = <optimized out>
> #26 0x000055e7740c8e8c in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7ffd6a2b1290)
> at ../../emacs/src/eval.c:3201
> count = {bytes = <optimized out>}
> val = <optimized out>
> #27 0x000055e7740c5dbe in internal_condition_case_n
> (bfun=bfun <at> entry=0x55e7740c8d90 <Ffuncall>, nargs=nargs <at> entry=2, args=args <at> entry=0x7ffd6a2b1290, handlers=handlers <at> entry=0x38, hfun=hfun <at> entry=0x55e773f4e550 <dsafe_eval_handler>) at ../../emacs/src/eval.c:1793
> val = <optimized out>
> c = 0x55e77bd0b710
> #28 0x000055e773f3bc04 in dsafe__call
> (inhibit_quit=inhibit_quit <at> entry=true, f=0x55e7740c8d90 <Ffuncall>, nargs=nargs <at> entry=2, args=args <at> entry=0x7ffd6a2b1290) at ../../emacs/src/xdisp.c:3106
> count = {bytes = <optimized out>}
> redisplay_counter_before = 939536
> val = <optimized out>
> #29 0x000055e773f6efbe in dsafe__call (inhibit_quit=true, nargs=2, f=<optimized out>, args=0x7ffd6a2b1290)
> at ../../emacs/src/xdisp.c:3094
> val = <optimized out>
> count = {bytes = <optimized out>}
> redisplay_counter_before = <optimized out>
> #30 prepare_menu_bars () at ../../emacs/src/xdisp.c:14060
This tels me that the crash happened insider prepare_menu_bars, which
called pre-redisplay-function. What is your value of
pre-redisplay-functions (note: "functions", plural)? The backtrace
indicates that treesit--pre-redisplay is involved; is that true?
I added Yuan, in case this is some treesit-related issue.
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Thu, 31 Jul 2025 05:43:01 GMT) Full text and rfc822 format available.Message #11 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Óscar Fuentes <oscarfv <at> eclipso.eu> Cc: 79131 <at> debbugs.gnu.org, Pip Cet <pipcet <at> protonmail.com> Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Thu, 31 Jul 2025 07:42:11 +0200
Óscar Fuentes <oscarfv <at> eclipso.eu> writes:
> #12 add_text_properties_1 (start=<optimized out>, start <at> entry=0x1f06a, end=<optimized out>,
> end <at> entry=0x1f07a, properties=0x7f4fe3c2acc3, object=0x7f4fe645cfbd,
> object <at> entry=0x0, set_type=set_type <at> entry=TEXT_PROPERTY_REPLACE, destructive=destructive <at> entry=true)
> --Type <RET> for more, q to quit, c to continue without paging--c
> at ../../emacs/src/textprop.c:1252
> i = 0x0
> unchanged = <optimized out>
> s = 31770
> len = 3
> modified = <optimized out>
> first_time = <optimized out>
That would be around here
textprop.c:
1251 /* We are at the beginning of interval I, with LEN chars to scan. */
1252 for (;;)
1253 {
1254 eassert (i != 0);
1255
1256 if (LENGTH (i) >= len)
1257 {
and that probably means i is NULL, which is a pointer to an interval. It
is accessed in LENGTH. Which in would mean that the interval tree is
kaput. Can you reproduce that?
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Thu, 31 Jul 2025 07:20:02 GMT) Full text and rfc822 format available.Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Óscar Fuentes via Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Óscar Fuentes <oscarfv <at> eclipso.eu>, 79131 <at> debbugs.gnu.org Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Thu, 31 Jul 2025 07:19:01 +0000
Óscar Fuentes via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> writes:
> This is a build of merging master's 6982dc460aa with current feature/igc
> HEAD (382123e69e2). I had to resolve some conflicts, so there is a
> possibility of the crash being caused by my mistake.
>
> Backtrace from the coredump:
It does look like the interval tree was in an inconsistent state.
Please run
p *current_buffer->text
in the coredump, then
p $i = current_buffer->text->intervals
and then repeat
p *$i
p $i = $i->right
until $i is NULL.
Also, can you print igc__balance_intervals to verify it's false?
Thanks!
Pip
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Thu, 31 Jul 2025 07:20:02 GMT) Full text and rfc822 format available.bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Thu, 31 Jul 2025 07:22:02 GMT) Full text and rfc822 format available.Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Pip Cet <pipcet <at> protonmail.com> Cc: Óscar Fuentes <oscarfv <at> eclipso.eu>, Óscar Fuentes via Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org>, 79131 <at> debbugs.gnu.org Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Thu, 31 Jul 2025 09:21:34 +0200
I'm in the process of merging master, BTW.
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Thu, 31 Jul 2025 07:22:02 GMT) Full text and rfc822 format available.bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Thu, 31 Jul 2025 07:47:02 GMT) Full text and rfc822 format available.Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Pip Cet <pipcet <at> protonmail.com> Cc: Óscar Fuentes <oscarfv <at> eclipso.eu>, Óscar Fuentes via Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org>, 79131 <at> debbugs.gnu.org Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Thu, 31 Jul 2025 09:46:23 +0200
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes: > I'm in the process of merging master, BTW. Done.
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Thu, 31 Jul 2025 07:47:02 GMT) Full text and rfc822 format available.bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Thu, 31 Jul 2025 09:27:01 GMT) Full text and rfc822 format available.Message #32 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Óscar Fuentes <oscarfv <at> eclipso.eu> To: Eli Zaretskii <eliz <at> gnu.org> Cc: gerd.moellmann <at> gmail.com, pipcet <at> protonmail.com, Yuan Fu <casouri <at> gmail.com>, 79131 <at> debbugs.gnu.org Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Thu, 31 Jul 2025 11:26:14 +0200
Eli, Gerd, Pip:
Eli Zaretskii <eliz <at> gnu.org> writes:
>> #12 add_text_properties_1 (start=<optimized out>, start <at> entry=0x1f06a, end=<optimized out>,
>> end <at> entry=0x1f07a, properties=0x7f4fe3c2acc3, object=0x7f4fe645cfbd,
>> object <at> entry=0x0, set_type=set_type <at> entry=TEXT_PROPERTY_REPLACE, destructive=destructive <at> entry=true)
>> --Type <RET> for more, q to quit, c to continue without paging--c
>> at ../../emacs/src/textprop.c:1252
>> i = 0x0
>> unchanged = <optimized out>
>> s = 31770
>> len = 3
>> modified = <optimized out>
>> first_time = <optimized out>
>
> Since this in code that is the result of your local merge, please be
> sure to show the source lines corresponding to the call-stack frames
> where the signal was raised. Otherwise, we are left guessing what is
> line 1252 in your version of textprop.c that could trigger SIGSEGV.
> My guess is that it's here:
>
>
> /* We are at the beginning of interval I, with LEN chars to scan. */
> for (;;)
> {
> eassert (i != 0);
>
> if (LENGTH (i) >= len) <<<<<<<<<<<<<<<<
>
> but I shouldn't be guessing. If my guess is correct, this is some
> snafu with intervals in the buffer that happens to be the current one.
textprop.c was not touched by the merge, is the same as master.
> This tels me that the crash happened insider prepare_menu_bars, which
> called pre-redisplay-function. What is your value of
> pre-redisplay-functions (note: "functions", plural)?
pre-redisplay-functions is a variable defined in ‘simple.el’.
Its value is (redisplay--update-region-highlight)
However, this is in my new session. The crashed one was running for
several days, and it is for sure that it had more features loaded that
the current one.
> The backtrace
> indicates that treesit--pre-redisplay is involved; is that true?
I was editing a file with a treesit-based major mode, that's all I can
say, as the Elisp backtrace is not available.
(gdb) xbacktrace
You can't do that without a process to debug.
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> That would be around here
>
> textprop.c:
> 1251 /* We are at the beginning of interval I, with LEN chars to scan. */
> 1252 for (;;)
> 1253 {
> 1254 eassert (i != 0);
> 1255
> 1256 if (LENGTH (i) >= len)
> 1257 {
>
> and that probably means i is NULL, which is a pointer to an interval. It
> is accessed in LENGTH. Which in would mean that the interval tree is
> kaput. Can you reproduce that?
No idea how to reproduce it, no.
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> I'm in the process of merging master, BTW.
>
> Done.
Thanks!
Pip Cet <pipcet <at> protonmail.com> writes:
> It does look like the interval tree was in an inconsistent state.
>
> Please run
>
> p *current_buffer->text
(gdb) fr 13
#13 0x000055e77414774b in Fadd_text_properties (start=make_fixnum(31770), end=make_fixnum(31774),
properties=<optimized out>, object=XIL(0)) at ../../emacs/src/textprop.c:1308
1308 return add_text_properties_1 (start, end, properties, object,
(gdb) p *current_buffer->text
$1 = {
beg = 0x55e77e157f80 "",
gpt = 1,
z = 31775,
gpt_byte = 1,
z_byte = 31793,
gap_size = 1153,
modiff = 53239,
chars_modiff = 53237,
save_modiff = 51987,
overlay_modiff = 55141,
compact = 53237,
beg_unchanged = 0,
end_unchanged = 1,
unchanged_modified = 53011,
overlay_unchanged_modified = 55141,
intervals = 0x7f4fe5280a28,
markers = XIL(0x7f4fdc5dc005),
inhibit_shrinking = false,
redisplay = true
}
> Also, can you print igc__balance_intervals to verify it's false?
(gdb) p igc__balance_intervals
$4 = false
> in the coredump, then
>
> p $i = current_buffer->text->intervals
(gdb) p $i = current_buffer->text->intervals
$2 = (INTERVAL) 0x7f4fe5280a28
> and then repeat
>
> p *$i
> p $i = $i->right
>
> until $i is NULL.
(gdb) p $i = current_buffer->text->intervals
$2 = (INTERVAL) 0x7f4fe5280a28
(gdb) p *$i
$3 = {
gc_header = {
v = 34955678229,
gcaligned = 21 '\025'
},
total_length = 31770,
position = 16392,
left = 0x7f4fe5281708,
right = 0x7f4fe5281748,
up = {
interval = 0x7f4fe645cfbd,
obj = XIL(0x7f4fe645cfbd)
},
up_obj = true,
gcmarkbit = false,
write_protect = false,
visible = false,
front_sticky = false,
rear_sticky = false,
plist = XIL(0x7f4fe528178b)
}
(gdb) p igc__balance_intervals
$4 = false
(gdb) p $i = $i->right
$5 = (struct interval *) 0x7f4fe5281748
(gdb) p *$i
$6 = {
gc_header = {
v = 35065123349,
gcaligned = 21 '\025'
},
total_length = 9680,
position = 25284,
left = 0x7f4fe5282220,
right = 0x7f4fe5284580,
up = {
interval = 0x7f4fe5280a28,
obj = XIL(0x7f4fe5280a28)
},
up_obj = false,
gcmarkbit = false,
write_protect = false,
visible = false,
front_sticky = false,
rear_sticky = false,
plist = XIL(0x7f4fe52822a3)
}
(gdb) p $i = $i->right
$7 = (struct interval *) 0x7f4fe5284580
(gdb) p *$i
$8 = {
gc_header = {
v = 35073341461,
gcaligned = 21 '\025'
},
total_length = 4210,
position = 30022,
left = 0x7f4fe64ae0b0,
right = 0x7f4fe5282260,
up = {
interval = 0x7f4fe5281748,
obj = XIL(0x7f4fe5281748)
},
up_obj = false,
gcmarkbit = false,
write_protect = false,
visible = false,
front_sticky = false,
rear_sticky = false,
plist = XIL(0x7f4fe26e87b3)
}
(gdb) p $i = $i->right
$9 = (struct interval *) 0x7f4fe5282260
(gdb) p *$i
$10 = {
gc_header = {
v = 35073261589,
gcaligned = 21 '\025'
},
total_length = 1748,
position = 30975,
left = 0x7f4fe632d920,
right = 0x7f4fe5283090,
up = {
interval = 0x7f4fe5284580,
obj = XIL(0x7f4fe5284580)
},
up_obj = false,
gcmarkbit = false,
write_protect = false,
visible = false,
front_sticky = false,
rear_sticky = false,
plist = XIL(0x7f4fe26ebedb)
}
(gdb) p $i = $i->right
$11 = (struct interval *) 0x7f4fe5283090
(gdb) p *$i
$12 = {
gc_header = {
v = 35073279509,
gcaligned = 21 '\025'
},
total_length = 787,
position = 31293,
left = 0x7f4fe5284618,
right = 0x7f4fe5284658,
up = {
interval = 0x7f4fe5282260,
obj = XIL(0x7f4fe5282260)
},
up_obj = false,
gcmarkbit = false,
write_protect = false,
visible = false,
front_sticky = false,
rear_sticky = false,
plist = XIL(0x7f4fe3c28afb)
}
(gdb) p $i = $i->right
$13 = (struct interval *) 0x7f4fe5284658
(gdb) p *$i
$14 = {
gc_header = {
v = 35073290261,
gcaligned = 21 '\025'
},
total_length = 471,
position = 31591,
left = 0x7f4fe545fc20,
right = 0x7f4fe55283b8,
up = {
interval = 0x7f4fe5283090,
obj = XIL(0x7f4fe5283090)
},
up_obj = false,
gcmarkbit = false,
write_protect = false,
visible = false,
front_sticky = false,
rear_sticky = false,
plist = XIL(0x7f4fe3c29fab)
}
(gdb) p $i = $i->right
$15 = (struct interval *) 0x7f4fe55283b8
(gdb) p *$i
$16 = {
gc_header = {
v = 38246400789,
gcaligned = 21 '\025'
},
total_length = 179,
position = 31675,
left = 0x7f4fe52ba358,
right = 0x7f4fe5286a28,
up = {
interval = 0x7f4fe5284658,
obj = XIL(0x7f4fe5284658)
},
up_obj = false,
gcmarkbit = false,
write_protect = false,
visible = false,
front_sticky = false,
rear_sticky = false,
plist = XIL(0x7f4fe3c2a5ab)
}
(gdb) p $i = $i->right
$17 = (struct interval *) 0x7f4fe5286a28
(gdb) p *$i
$18 = {
gc_header = {
v = 35073301013,
gcaligned = 21 '\025'
},
total_length = 95,
position = 31705,
left = 0x7f4fe61681b8,
right = 0x7f4fe52ac5c0,
up = {
interval = 0x7f4fe55283b8,
obj = XIL(0x7f4fe55283b8)
},
up_obj = false,
gcmarkbit = false,
write_protect = false,
visible = false,
front_sticky = false,
rear_sticky = false,
plist = XIL(0x7f4fe3c2a7eb)
}
(gdb) p $i = $i->right
$19 = (struct interval *) 0x7f4fe52ac5c0
(gdb) p *$i
$20 = {
gc_header = {
v = 35073731093,
gcaligned = 21 '\025'
},
total_length = 60,
position = 31740,
left = 0x7f4fe52ba3f0,
right = 0x7f4fe52ba430,
up = {
interval = 0x7f4fe5286a28,
obj = XIL(0x7f4fe5286a28)
},
up_obj = false,
gcmarkbit = false,
write_protect = false,
visible = false,
front_sticky = false,
rear_sticky = false,
plist = XIL(0x7f4fe3c2ab1b)
}
(gdb) p $i = $i->right
$21 = (struct interval *) 0x7f4fe52ba430
(gdb) p *$i
$22 = {
gc_header = {
v = 35073096981,
gcaligned = 21 '\025'
},
total_length = 30,
position = 31736,
left = 0x7f4fe52c7b50,
right = 0x7f4fe52c7b90,
up = {
interval = 0x7f4fe52ac5c0,
obj = XIL(0x7f4fe52ac5c0)
},
up_obj = false,
gcmarkbit = false,
write_protect = false,
visible = false,
front_sticky = false,
rear_sticky = false,
plist = XIL(0x7f4fe52d076b)
}
(gdb) p $i = $i->right
$23 = (struct interval *) 0x7f4fe52c7b90
(gdb) p *$i
$24 = {
gc_header = {
v = 35073148437,
gcaligned = 21 '\025'
},
total_length = 10,
position = 31745,
left = 0x7f4fe52d0108,
right = 0x7f4fe52d0148,
up = {
interval = 0x7f4fe52ba430,
obj = XIL(0x7f4fe52ba430)
},
up_obj = false,
gcmarkbit = false,
write_protect = false,
visible = false,
front_sticky = false,
rear_sticky = false,
plist = XIL(0x7f4fe52d0c23)
}
(gdb) p $i = $i->right
$25 = (struct interval *) 0x7f4fe52d0148
(gdb) p *$i
$26 = {
gc_header = {
v = 35073154325,
gcaligned = 21 '\025'
},
total_length = 5,
position = 31752,
left = 0x7f4fe52d06b8,
right = 0x7f4fe52d06f8,
up = {
interval = 0x7f4fe52c7b90,
obj = XIL(0x7f4fe52c7b90)
},
up_obj = false,
gcmarkbit = false,
write_protect = false,
visible = false,
front_sticky = false,
rear_sticky = false,
plist = XIL(0x7f4fe64c0a73)
}
(gdb) p $i = $i->right
$27 = (struct interval *) 0x7f4fe52d06f8
(gdb) p *$i
$28 = {
gc_header = {
v = 35073135893,
gcaligned = 21 '\025'
},
total_length = 1,
position = 31770,
left = 0x0,
right = 0x0,
up = {
interval = 0x7f4fe52d0148,
obj = XIL(0x7f4fe52d0148)
},
up_obj = false,
gcmarkbit = false,
write_protect = false,
visible = false,
front_sticky = false,
rear_sticky = false,
plist = XIL(0x7f4fe3c2acf3)
}
(gdb) p $i = $i->right
$29 = (struct interval *) 0x0
(gdb) p *$i
Cannot access memory at address 0x0
(gdb)
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Sat, 02 Aug 2025 00:10:01 GMT) Full text and rfc822 format available.Message #35 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Yuan Fu <casouri <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: gerd.moellmann <at> gmail.com, Óscar Fuentes <oscarfv <at> eclipso.eu>, 79131 <at> debbugs.gnu.org, pipcet <at> protonmail.com Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Fri, 1 Aug 2025 17:09:08 -0700
> On Jul 30, 2025, at 10:11 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> Cc: Pip Cet <pipcet <at> protonmail.com>,
>> Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Date: Wed, 30 Jul 2025 22:18:44 +0200
>> From: Óscar Fuentes via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>>
>> This is a build of merging master's 6982dc460aa with current feature/igc
>> HEAD (382123e69e2). I had to resolve some conflicts, so there is a
>> possibility of the crash being caused by my mistake.
>>
>> Backtrace from the coredump:
>>
>> (gdb) bt full
>> #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo <at> entry=11, no_tid=no_tid <at> entry=0)
>> at ./nptl/pthread_kill.c:44
>> tid = <optimized out>
>> ret = 0
>> pd = <optimized out>
>> old_mask = {__val = {94452575465120}}
>> ret = <optimized out>
>> #1 0x00007f506ce9e9ff in __pthread_kill_internal (threadid=<optimized out>, signo=11)
>> at ./nptl/pthread_kill.c:89
>> #2 0x00007f506ce49cc2 in __GI_raise (sig=sig <at> entry=11) at ../sysdeps/posix/raise.c:26
>> ret = <optimized out>
>> #3 0x000055e773f12db8 in terminate_due_to_signal
>> (sig=sig <at> entry=11, backtrace_limit=backtrace_limit <at> entry=40) at ../../emacs/src/emacs.c:481
>> #4 0x000055e773f132de in handle_fatal_signal (sig=sig <at> entry=11) at ../../emacs/src/sysdep.c:1793
>> #5 0x000055e773f132e5 in deliver_thread_signal
>> (sig=sig <at> entry=11, handler=0x55e773f132d0 <handle_fatal_signal>) at ../../emacs/src/sysdep.c:1785
>> old_errno = <optimized out>
>> #6 0x000055e774058dec in deliver_fatal_thread_signal (sig=11) at ../../emacs/src/sysdep.c:1805
>> #7 handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at ../../emacs/src/sysdep.c:1943
>> fatal = <optimized out>
>> #8 0x00007f506ce49df0 in <signal handler called> () at /lib/x86_64-linux-gnu/libc.so.6
>> #9 0x00007f506ce4a007 in __GI_kill () at ../sysdeps/unix/syscall-template.S:120
>> #10 0x000055e774215e44 in sigHandle ()
>> #11 0x00007f506ce49df0 in <signal handler called> () at /lib/x86_64-linux-gnu/libc.so.6
>> #12 add_text_properties_1 (start=<optimized out>, start <at> entry=0x1f06a, end=<optimized out>,
>> end <at> entry=0x1f07a, properties=0x7f4fe3c2acc3, object=0x7f4fe645cfbd,
>> object <at> entry=0x0, set_type=set_type <at> entry=TEXT_PROPERTY_REPLACE, destructive=destructive <at> entry=true)
>> --Type <RET> for more, q to quit, c to continue without paging--c
>> at ../../emacs/src/textprop.c:1252
>> i = 0x0
>> unchanged = <optimized out>
>> s = 31770
>> len = 3
>> modified = <optimized out>
>> first_time = <optimized out>
>
> Since this in code that is the result of your local merge, please be
> sure to show the source lines corresponding to the call-stack frames
> where the signal was raised. Otherwise, we are left guessing what is
> line 1252 in your version of textprop.c that could trigger SIGSEGV.
> My guess is that it's here:
>
>
> /* We are at the beginning of interval I, with LEN chars to scan. */
> for (;;)
> {
> eassert (i != 0);
>
> if (LENGTH (i) >= len) <<<<<<<<<<<<<<<<
>
> but I shouldn't be guessing. If my guess is correct, this is some
> snafu with intervals in the buffer that happens to be the current one.
>
>> #13 0x000055e77414774b in Fadd_text_properties
>> (start=0x1f06a, end=0x1f07a, properties=<optimized out>, object=0x0) at ../../emacs/src/textprop.c:1308
>> #14 Fput_text_property
>> (start=0x1f06a, end=0x1f07a, property=<optimized out>, value=<optimized out>, object=0x0)
>> at ../../emacs/src/textprop.c:1326
>> properties = <optimized out>
>> #15 0x00007f505801aec2 in F747265657369742d2d666f6e742d6c6f636b2d6d61726b2d72616e6765732d746f2d666f6e74696679_treesit__font_lock_mark_ranges_to_fontify_0 ()
>> at /home/oscar/.emacs.d/eln-cache/31.0.50-3eae311e/treesit-37439c61-2c208e3a.eln
>> #16 0x000055e7740c8e8c in Ffuncall (nargs=2, args=0x7ffd6a2b0e70) at ../../emacs/src/eval.c:3201
>> count = {bytes = <optimized out>}
>> val = <optimized out>
>> #17 0x00007f505801b396 in F747265657369742d2d7072652d7265646973706c6179_treesit__pre_redisplay_0 ()
>> at /home/oscar/.emacs.d/eln-cache/31.0.50-3eae311e/treesit-37439c61-2c208e3a.eln
>> #18 0x000055e7740c8e8c in Ffuncall (nargs=2, args=0x7ffd6a2b0f80) at ../../emacs/src/eval.c:3201
>> count = {bytes = <optimized out>}
>> val = <optimized out>
>> #19 0x000055e7740c90e9 in funcall_nil (nargs=<optimized out>, args=<optimized out>)
>> at ../../emacs/src/eval.c:2884
>> #20 0x000055e7740c643d in run_hook_with_args
>> (nargs=2, args=0x7ffd6a2b0f80, funcall=0x55e7740c90e0 <funcall_nil>) at ../../emacs/src/eval.c:3061
>> global_vals = <optimized out>
>> sym = 0x2968c2d2eba0
>> val = 0x7f4fe52f5c83
>> ret = 0x0
>> #21 0x000055e7740c8e8c in Ffuncall (nargs=3, args=0x7ffd6a2b0f78) at ../../emacs/src/eval.c:3201
>> count = {bytes = <optimized out>}
>> val = <optimized out>
>> #22 0x00007f505b7c1d34 in F7265646973706c61792d2d7072652d7265646973706c61792d66756e6374696f6e73_redisplay__pre_redisplay_functions_0 ()
>> at /home/oscar/dev/emacs/igc/build/src/../native-lisp/31.0.50-3eae311e/preloaded/simple-fab5b0cf-fea6411a.eln
>> #23 0x000055e7740c8e8c in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7f505ad28040)
>> at ../../emacs/src/eval.c:3201
>> count = {bytes = <optimized out>}
>> val = <optimized out>
>> #24 0x000055e7740c7742 in Fapply (nargs=2, args=0x7f505ad28040) at ../../emacs/src/eval.c:2830
>> i = <optimized out>
>> funcall_nargs = <optimized out>
>> funcall_args = 0x0
>> spread_arg = <optimized out>
>> fun = 0x2968f6dc91d8
>> sa_avail = 16384
>> sa_count = {bytes = <optimized out>}
>> numargs = <optimized out>
>> retval = <optimized out>
>> #25 0x000055e77411753a in exec_byte_code
>> (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
>> at ../../emacs/src/lisp.h:2306
>> call_nargs = 2
>> call_fun = <optimized out>
>> count1 = {bytes = <optimized out>}
>> val = <optimized out>
>> call_args = 0x7f505ad28040
>> original_fun = 0x43d0
>> op = 2
>> type = <optimized out>
>> targets = {0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e77411793f <exec_byte_code+2047>, 0x55e77411793a <exec_byte_code+2042>, 0x55e774117935 <exec_byte_code+2037>, 0x55e77411731d <exec_byte_code+477>, 0x55e77411731d <exec_byte_code+477>, 0x55e7741178f7 <exec_byte_code+1975>, 0x55e7741178b9 <exec_byte_code+1913>, 0x55e7741198e2 <exec_byte_code+10146>, 0x55e7741198dd <exec_byte_code+10141>, 0x55e7741198d8 <exec_byte_code+10136>, 0x55e7741198d3 <exec_byte_code+10131>, 0x55e774117357 <exec_byte_code+535>, 0x55e774117360 <exec_byte_code+544>, 0x55e7741198c6 <exec_byte_code+10118>, 0x55e7741198e7 <exec_byte_code+10151>, 0x55e77411976e <exec_byte_code+9774>, 0x55e774119769 <exec_byte_code+9769>, 0x55e774119764 <exec_byte_code+9764>, 0x55e77411975f <exec_byte_code+9759>, 0x55e7741172b9 <exec_byte_code+377>, 0x55e7741172c0 <exec_byte_code+384>, 0x55e774119745 <exec_byte_code+9733>, 0x55e774119752 <exec_byte_code+9746>, 0x55e7741196f3 <exec_byte_code+9651>, 0x55e7741196ee <exec_byte_code+9646>, 0x55e7741196e9 <exec_byte_code+9641>, 0x55e7741196e4 <exec_byte_code+9636>, 0x55e7741175ef <exec_byte_code+1199>, 0x55e7741175f0 <exec_byte_code+1200>, 0x55e774119705 <exec_byte_code+9669>, 0x55e7741196f8 <exec_byte_code+9656>, 0x55e7741196c5 <exec_byte_code+9605>, 0x55e7741196c0 <exec_byte_code+9600>, 0x55e7741196bb <exec_byte_code+9595>, 0x55e7741196b6 <exec_byte_code+9590>, 0x55e7741173bd <exec_byte_code+637>, 0x55e7741173c0 <exec_byte_code+640>, 0x55e7741196d7 <exec_byte_code+9623>, 0x55e7741196ca <exec_byte_code+9610>, 0x55e774119697 <exec_byte_code+9559>, 0x55e774119692 <exec_byte_code+9554>, 0x55e77411968d <exec_byte_code+9549>, 0x55e774119688 <exec_byte_code+9544>, 0x55e774117639 <exec_byte_code+1273>, 0x55e774117640 <exec_byte_code+1280>, 0x55e7741196a9 <exec_byte_code+9577>, 0x55e77411969c <exec_byte_code+9564>, 0x55e774119273 <exec_byte_code+8499>, 0x55e7741192a7 <exec_byte_code+8551>, 0x55e774119330 <exec_byte_code+8688>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e7741190c7 <exec_byte_code+8071>, 0x55e774119054 <exec_byte_code+7956>, 0x55e77411900d <exec_byte_code+7885>, 0x55e774118fc6 <exec_byte_code+7814>, 0x55e774118f81 <exec_byte_code+7745>, 0x55e7741197ef <exec_byte_code+9903>, 0x55e7741197af <exec_byte_code+9839>, 0x55e774118f4f <exec_byte_code+7695>, 0x55e77411984b <exec_byte_code+9995>, 0x55e774119773 <exec_byte_code+9779>, 0x55e774118f0f <exec_byte_code+7631>, 0x55e774118edf <exec_byte_code+7583>, 0x55e774118e9f <exec_byte_code+7519>, 0x55e774118e62 <exec_byte_code+7458>, 0x55e774118e21 <exec_byte_code+7393>, 0x55e774118dab <exec_byte_code+7275>, 0x55e774118d20 <exec_byte_code+7136>, 0x55e774118c8b <exec_byte_code+6987>, 0x55e774118c5b <exec_byte_code+6939>, 0x55e774118c2b <exec_byte_code+6891>, 0x55e774118beb <exec_byte_code+6827>, 0x55e774118bab <exec_byte_code+6763>, 0x55e774118b6b <exec_byte_code+6699>, 0x55e774118b27 <exec_byte_code+6631>, 0x55e774118aed <exec_byte_code+6573>, 0x55e774118ab3 <exec_byte_code+6515>, 0x55e774118a79 <exec_byte_code+6457>, 0x55e7741189d7 <exec_byte_code+6295>, 0x55e77411897b <exec_byte_code+6203>, 0x55e774118921 <exec_byte_code+6113>, 0x55e7741188c7 <exec_byte_code+6023>, 0x55e77411886d <exec_byte_code+5933>, 0x55e774118813 <exec_byte_code+5843>, 0x55e7741187b9 <exec_byte_code+5753>, 0x55e774118761 <exec_byte_code+5665>, 0x55e774118704 <exec_byte_code+5572>, 0x55e7741186ac <exec_byte_code+5484>, 0x55e774118654 <exec_byte_code+5396>, 0x55e7741185fc <exec_byte_code+5308>, 0x55e7741185a3 <exec_byte_code+5219>, 0x55e7741184b2 <exec_byte_code+4978>, 0x55e774117689 <exec_byte_code+1353>, 0x55e774118482 <exec_byte_code+4930>, 0x55e77411844d <exec_byte_code+4877>, 0x55e7741183bd <exec_byte_code+4733>, 0x55e774118373 <exec_byte_code+4659>, 0x55e774118343 <exec_byte_code+4611>, 0x55e774118311 <exec_byte_code+4561>, 0x55e7741182df <exec_byte_code+4511>, 0x55e7741182a5 <exec_byte_code+4453>, 0x55e774118273 <exec_byte_code+4403>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e774118241 <exec_byte_code+4353>, 0x55e77411820f <exec_byte_code+4303>, 0x55e7741181dd <exec_byte_code+4253>, 0x55e7741181ab <exec_byte_code+4203>, 0x55e774118179 <exec_byte_code+4153>, 0x55e774118149 <exec_byte_code+4105>, 0x55e774117689 <exec_byte_code+1353>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e774118105 <exec_byte_code+4037>, 0x55e7741180d4 <exec_byte_code+3988>, 0x55e7741180a3 <exec_byte_code+3939>, 0x55e774118062 <exec_byte_code+3874>, 0x55e774118021 <exec_byte_code+3809>, 0x55e774117ff0 <exec_byte_code+3760>, 0x55e774117fbf <exec_byte_code+3711>, 0x55e774117f7e <exec_byte_code+3646>, 0x55e774117f3d <exec_byte_code+3581>, 0x55e774117efc <exec_byte_code+3516>, 0x55e774117ec9 <exec_byte_code+3465>, 0x55e774117e98 <exec_byte_code+3416>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e77411943f <exec_byte_code+8959>, 0x55e774119615 <exec_byte_code+9429>, 0x55e774119887 <exec_byte_code+10055>, 0x55e7741195d6 <exec_byte_code+9366>, 0x55e77411959a <exec_byte_code+9306>, 0x55e77411955e <exec_byte_code+9246>, 0x55e77411949d <exec_byte_code+9053>, 0x55e774119478 <exec_byte_code+9016>, 0x55e774119712 <exec_byte_code+9682>, 0x55e77411941a <exec_byte_code+8922>, 0x55e7741193b7 <exec_byte_code+8823>, 0x55e774119382 <exec_byte_code+8770>, 0x55e77411933b <exec_byte_code+8699>, 0x55e77411921e <exec_byte_code+8414>, 0x55e7741191da <exec_byte_code+8346>, 0x55e774119190 <exec_byte_code+8272>, 0x55e774119125 <exec_byte_code+8165>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e774117e53 <exec_byte_code+3347>, 0x55e774117e22 <exec_byte_code+3298>, 0x55e774117df1 <exec_byte_code+3249>, 0x55e774117dc0 <exec_byte_code+3200>, 0x55e774117d8f <exec_byte_code+3151>, 0x55e774117d4e <exec_byte_code+3086>, 0x55e774117d0d <exec_byte_code+3021>, 0x55e774117ccc <exec_byte_code+2956>, 0x55e774117c8b <exec_byte_code+2891>, 0x55e774117c24 <exec_byte_code+2788>, 0x55e774117be3 <exec_byte_code+2723>, 0x55e774117ba2 <exec_byte_code+2658>, 0x55e774117b71 <exec_byte_code+2609>, 0x55e774117b25 <exec_byte_code+2533>, 0x55e774117ad9 <exec_byte_code+2457>, 0x55e774117a9b <exec_byte_code+2395>, 0x55e774117a5d <exec_byte_code+2333>, 0x55e774117a22 <exec_byte_code+2274>, 0x55e77411854b <exec_byte_code+5131>, 0x55e7741184fc <exec_byte_code+5052>, 0x55e7741179b2 <exec_byte_code+2162>, 0x55e774117944 <exec_byte_code+2052>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e774118ddb <exec_byte_code+7323>, 0x55e774118a33 <exec_byte_code+6387>, 0x55e774118407 <exec_byte_code+4807>, 0x55e774117873 <exec_byte_code+1843>, 0x55e77411782d <exec_byte_code+1773>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e7741177f4 <exec_byte_code+1716>, 0x55e774117790 <exec_byte_code+1616>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e773f17ee1 <exec_byte_code-2093663>, 0x55e774117756 <exec_byte_code+1558> <repeats 64 times>}
>> quitcounter = <optimized out>
>> bc = 0x55e7742cb858 <main_thread+312>
>> top = 0x7f505ad28038
>> pc = <optimized out>
>> bytestr = <optimized out>
>> vector = <optimized out>
>> maxdepth = <optimized out>
>> const_length = <optimized out>
>> bytestr_length = <optimized out>
>> vectorp = 0x7f506b0a53f0
>> max_stack = <optimized out>
>> frame_base = <optimized out>
>> fp = <optimized out>
>> bytestr_data = <optimized out>
>> rest = <optimized out>
>> mandatory = <optimized out>
>> nonrest = <optimized out>
>> pushedargs = <optimized out>
>> saved_quitcounter = 0 '\000'
>> saved_vectorp = 0xdd98
>> saved_bytestr_data = 0x7ffd00000002 <error: Cannot access memory at address 0x7ffd00000002>
>> result = <optimized out>
>> #26 0x000055e7740c8e8c in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7ffd6a2b1290)
>> at ../../emacs/src/eval.c:3201
>> count = {bytes = <optimized out>}
>> val = <optimized out>
>> #27 0x000055e7740c5dbe in internal_condition_case_n
>> (bfun=bfun <at> entry=0x55e7740c8d90 <Ffuncall>, nargs=nargs <at> entry=2, args=args <at> entry=0x7ffd6a2b1290, handlers=handlers <at> entry=0x38, hfun=hfun <at> entry=0x55e773f4e550 <dsafe_eval_handler>) at ../../emacs/src/eval.c:1793
>> val = <optimized out>
>> c = 0x55e77bd0b710
>> #28 0x000055e773f3bc04 in dsafe__call
>> (inhibit_quit=inhibit_quit <at> entry=true, f=0x55e7740c8d90 <Ffuncall>, nargs=nargs <at> entry=2, args=args <at> entry=0x7ffd6a2b1290) at ../../emacs/src/xdisp.c:3106
>> count = {bytes = <optimized out>}
>> redisplay_counter_before = 939536
>> val = <optimized out>
>> #29 0x000055e773f6efbe in dsafe__call (inhibit_quit=true, nargs=2, f=<optimized out>, args=0x7ffd6a2b1290)
>> at ../../emacs/src/xdisp.c:3094
>> val = <optimized out>
>> count = {bytes = <optimized out>}
>> redisplay_counter_before = <optimized out>
>> #30 prepare_menu_bars () at ../../emacs/src/xdisp.c:14060
>
> This tels me that the crash happened insider prepare_menu_bars, which
> called pre-redisplay-function. What is your value of
> pre-redisplay-functions (note: "functions", plural)? The backtrace
> indicates that treesit--pre-redisplay is involved; is that true?
>
> I added Yuan, in case this is some treesit-related issue.
Treesit--pre-redisplay (optionally) parses the buffer and marks regions of text with fontified=nil so redisplay will re-fontify them. If that’s of any help.
Yuan
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Sun, 03 Aug 2025 13:35:02 GMT) Full text and rfc822 format available.Message #38 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Óscar Fuentes <oscarfv <at> eclipso.eu> Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 79131 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com> Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Sun, 03 Aug 2025 13:34:18 +0000
Óscar Fuentes <oscarfv <at> eclipso.eu> writes:
> Eli, Gerd, Pip:
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> #12 add_text_properties_1 (start=<optimized out>, start <at> entry=0x1f06a, end=<optimized out>,
>>> end <at> entry=0x1f07a, properties=0x7f4fe3c2acc3, object=0x7f4fe645cfbd,
>>> object <at> entry=0x0, set_type=set_type <at> entry=TEXT_PROPERTY_REPLACE, destructive=destructive <at> entry=true)
>>> --Type <RET> for more, q to quit, c to continue without paging--c
>>> at ../../emacs/src/textprop.c:1252
>>> i = 0x0
>>> unchanged = <optimized out>
>>> s = 31770
>>> len = 3
>>> modified = <optimized out>
>>> first_time = <optimized out>
>>
>> Since this in code that is the result of your local merge, please be
>> sure to show the source lines corresponding to the call-stack frames
>> where the signal was raised. Otherwise, we are left guessing what is
>> line 1252 in your version of textprop.c that could trigger SIGSEGV.
>> My guess is that it's here:
>>
>>
>> /* We are at the beginning of interval I, with LEN chars to scan. */
>> for (;;)
>> {
>> eassert (i != 0);
>>
>> if (LENGTH (i) >= len) <<<<<<<<<<<<<<<<
>>
>> but I shouldn't be guessing. If my guess is correct, this is some
>> snafu with intervals in the buffer that happens to be the current one.
>
> textprop.c was not touched by the merge, is the same as master.
>
>> This tels me that the crash happened insider prepare_menu_bars, which
>> called pre-redisplay-function. What is your value of
>> pre-redisplay-functions (note: "functions", plural)?
>
> pre-redisplay-functions is a variable defined in ‘simple.el’.
>
> Its value is (redisplay--update-region-highlight)
>
> However, this is in my new session. The crashed one was running for
> several days, and it is for sure that it had more features loaded that
> the current one.
>
>> The backtrace
>> indicates that treesit--pre-redisplay is involved; is that true?
>
> I was editing a file with a treesit-based major mode, that's all I can
> say, as the Elisp backtrace is not available.
>
> (gdb) xbacktrace
> You can't do that without a process to debug.
>
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> That would be around here
>>
>> textprop.c:
>> 1251 /* We are at the beginning of interval I, with LEN chars to scan. */
>> 1252 for (;;)
>> 1253 {
>> 1254 eassert (i != 0);
>> 1255
>> 1256 if (LENGTH (i) >= len)
>> 1257 {
>>
>> and that probably means i is NULL, which is a pointer to an interval. It
>> is accessed in LENGTH. Which in would mean that the interval tree is
>> kaput. Can you reproduce that?
>
> No idea how to reproduce it, no.
>
>
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>>> I'm in the process of merging master, BTW.
>>
>> Done.
>
> Thanks!
>
>
> Pip Cet <pipcet <at> protonmail.com> writes:
>
>> It does look like the interval tree was in an inconsistent state.
>>
>> Please run
>>
>> p *current_buffer->text
>
>
> (gdb) fr 13
> #13 0x000055e77414774b in Fadd_text_properties (start=make_fixnum(31770), end=make_fixnum(31774),
> properties=<optimized out>, object=XIL(0)) at ../../emacs/src/textprop.c:1308
> 1308 return add_text_properties_1 (start, end, properties, object,
> (gdb) p *current_buffer->text
> $1 = {
> beg = 0x55e77e157f80 "",
> gpt = 1,
> z = 31775,
I think Z = 31775 should mean that the interval tree covers 31775
characters.
> (gdb) p $i = current_buffer->text->intervals
> $2 = (INTERVAL) 0x7f4fe5280a28
> (gdb) p *$i
> $3 = {
> gc_header = {
> v = 34955678229,
> gcaligned = 21 '\025'
> },
> total_length = 31770,
But the interval tree only covers 31770 characters.
> (gdb) p *$i
> $28 = {
> gc_header = {
> v = 35073135893,
> gcaligned = 21 '\025'
> },
> total_length = 1,
> position = 31770,
> left = 0x0,
> right = 0x0,
Assuming that this interval's "position" cache is correct (I think it
should be), the code that crashed would try to move on to the next
interval, which doesn't exist, fall off the end of the world and crash.
But I don't know the interval code that well; is it possible that's a
valid interval tree if the last few characters don't have properties?
I looked around a little, but I don't really see any MPS-specific code
which might violate this invariant.
Can you have a look at what current_buffer actually contains? The
contents should start at current_buffer->text.beg + 1153, after the gap,
an we're particularly interested in the last few bytes and the bytes
around PT.
So can you try
p current_buffer->pt
p *XSTRING(current_buffer->name_)
p current_buffer->beg + 1153
p current_buffer->beg + 1153 + 31770 - 64
Thanks!
Pip
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Sun, 03 Aug 2025 14:07:01 GMT) Full text and rfc822 format available.Message #41 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Pip Cet <pipcet <at> protonmail.com> Cc: Óscar Fuentes <oscarfv <at> eclipso.eu>, Eli Zaretskii <eliz <at> gnu.org>, 79131 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com> Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Sun, 03 Aug 2025 16:06:00 +0200
Pip Cet <pipcet <at> protonmail.com> writes:
> Assuming that this interval's "position" cache is correct (I think it
> should be), the code that crashed would try to move on to the next
> interval, which doesn't exist, fall off the end of the world and crash.
>
> But I don't know the interval code that well; is it possible that's a
> valid interval tree if the last few characters don't have properties?
I think an invariant of the interval tree is that it always covers the
whole buffer. We start with
intervals.c<cl-packages>:
86 INTERVAL
87 create_root_interval (Lisp_Object parent)
88 {
89 INTERVAL new;
90
91 new = make_interval ();
92
93 if (! STRINGP (parent))
94 {
95 new->total_length = (BUF_Z (XBUFFER (parent))
96 - BUF_BEG (XBUFFER (parent)));
97 eassert (TOTAL_LENGTH (new) >= 0);
98 set_buffer_intervals (XBUFFER (parent), new);
99 new->position = BEG;
where one can see that. Adding text properties splits that interval and
so on, but the total length covered should be the buffer size.
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Sun, 03 Aug 2025 14:47:01 GMT) Full text and rfc822 format available.Message #44 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Óscar Fuentes <oscarfv <at> eclipso.eu> To: Pip Cet <pipcet <at> protonmail.com> Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 79131 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com> Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Sun, 03 Aug 2025 16:46:47 +0200
Pip Cet <pipcet <at> protonmail.com> writes:
> So can you try
>
> p current_buffer->pt
(gdb) fr 13
#13 0x000055e77414774b in Fadd_text_properties (start=0x1f06a, end=0x1f07a, properties=<optimized out>,
object=0x0) at ../../emacs/src/textprop.c:1308
1308 return add_text_properties_1 (start, end, properties, object,
(gdb) p current_buffer->pt
$1 = 5961
> p *XSTRING(current_buffer->name_)
(gdb) p *XSTRING(current_buffer->name_)
No symbol "XSTRING" in current context.
> p current_buffer->beg + 1153
(gdb) p current_buffer->beg + 1153
There is no member named beg.
(gdb) p current_buffer->text->beg + 1153
$3 = (unsigned char *) 0x55e77e158401 <first lines of buffer>
> p current_buffer->beg + 1153 + 31770 - 64
(gdb) p current_buffer->text->beg + 1153 + 31770 - 64
$4 = (unsigned char *) 0x55e77e15ffdb <last lines of buffer>
Actually:
(gdb) p current_buffer->text->beg + 1153 + 31770
$6 = (unsigned char *) 0x55e77e16001b
shows the last 22 characters of the buffer without garbage at the end.
It doesn't look like a buffer overrun.
Probably you are right and this is not a MPS-related crash.
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Sun, 03 Aug 2025 14:48:02 GMT) Full text and rfc822 format available.Message #47 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Óscar Fuentes <oscarfv <at> eclipso.eu> Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 79131 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com> Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Sun, 03 Aug 2025 14:47:29 +0000
Pip Cet <pipcet <at> protonmail.com> writes:
> Óscar Fuentes <oscarfv <at> eclipso.eu> writes:
>
>> Eli, Gerd, Pip:
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> #12 add_text_properties_1 (start=<optimized out>, start <at> entry=0x1f06a, end=<optimized out>,
>>>> end <at> entry=0x1f07a, properties=0x7f4fe3c2acc3, object=0x7f4fe645cfbd,
>>>> object <at> entry=0x0, set_type=set_type <at> entry=TEXT_PROPERTY_REPLACE, destructive=destructive <at> entry=true)
>>>> --Type <RET> for more, q to quit, c to continue without paging--c
>>>> at ../../emacs/src/textprop.c:1252
>>>> i = 0x0
>>>> unchanged = <optimized out>
>>>> s = 31770
>>>> len = 3
>>>> modified = <optimized out>
>>>> first_time = <optimized out>
>>>
>>> Since this in code that is the result of your local merge, please be
>>> sure to show the source lines corresponding to the call-stack frames
>>> where the signal was raised. Otherwise, we are left guessing what is
>>> line 1252 in your version of textprop.c that could trigger SIGSEGV.
>>> My guess is that it's here:
>>>
>>>
>>> /* We are at the beginning of interval I, with LEN chars to scan. */
>>> for (;;)
>>> {
>>> eassert (i != 0);
>>>
>>> if (LENGTH (i) >= len) <<<<<<<<<<<<<<<<
>>>
>>> but I shouldn't be guessing. If my guess is correct, this is some
>>> snafu with intervals in the buffer that happens to be the current one.
>>
>> textprop.c was not touched by the merge, is the same as master.
>>
>>> This tels me that the crash happened insider prepare_menu_bars, which
>>> called pre-redisplay-function. What is your value of
>>> pre-redisplay-functions (note: "functions", plural)?
>>
>> pre-redisplay-functions is a variable defined in ‘simple.el’.
>>
>> Its value is (redisplay--update-region-highlight)
>>
>> However, this is in my new session. The crashed one was running for
>> several days, and it is for sure that it had more features loaded that
>> the current one.
>>
>>> The backtrace
>>> indicates that treesit--pre-redisplay is involved; is that true?
>>
>> I was editing a file with a treesit-based major mode, that's all I can
>> say, as the Elisp backtrace is not available.
>>
>> (gdb) xbacktrace
>> You can't do that without a process to debug.
>>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>>> That would be around here
>>>
>>> textprop.c:
>>> 1251 /* We are at the beginning of interval I, with LEN chars to scan. */
>>> 1252 for (;;)
>>> 1253 {
>>> 1254 eassert (i != 0);
>>> 1255
>>> 1256 if (LENGTH (i) >= len)
>>> 1257 {
>>>
>>> and that probably means i is NULL, which is a pointer to an interval. It
>>> is accessed in LENGTH. Which in would mean that the interval tree is
>>> kaput. Can you reproduce that?
>>
>> No idea how to reproduce it, no.
>>
>>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>>
>>>> I'm in the process of merging master, BTW.
>>>
>>> Done.
>>
>> Thanks!
>>
>>
>> Pip Cet <pipcet <at> protonmail.com> writes:
>>
>>> It does look like the interval tree was in an inconsistent state.
>>>
>>> Please run
>>>
>>> p *current_buffer->text
>>
>>
>> (gdb) fr 13
>> #13 0x000055e77414774b in Fadd_text_properties (start=make_fixnum(31770), end=make_fixnum(31774),
>> properties=<optimized out>, object=XIL(0)) at ../../emacs/src/textprop.c:1308
>> 1308 return add_text_properties_1 (start, end, properties, object,
>> (gdb) p *current_buffer->text
>> $1 = {
>> beg = 0x55e77e157f80 "",
>> gpt = 1,
>> z = 31775,
>
> I think Z = 31775 should mean that the interval tree covers 31775
> characters.
>
>> (gdb) p $i = current_buffer->text->intervals
>> $2 = (INTERVAL) 0x7f4fe5280a28
>> (gdb) p *$i
>> $3 = {
>> gc_header = {
>> v = 34955678229,
>> gcaligned = 21 '\025'
>> },
>> total_length = 31770,
>
> But the interval tree only covers 31770 characters.
>
>> (gdb) p *$i
>> $28 = {
>> gc_header = {
>> v = 35073135893,
>> gcaligned = 21 '\025'
>> },
>> total_length = 1,
>> position = 31770,
>> left = 0x0,
>> right = 0x0,
>
> Assuming that this interval's "position" cache is correct (I think it
> should be), the code that crashed would try to move on to the next
> interval, which doesn't exist, fall off the end of the world and crash.
>
> But I don't know the interval code that well; is it possible that's a
> valid interval tree if the last few characters don't have properties?
>
> I looked around a little, but I don't really see any MPS-specific code
> which might violate this invariant.
>
> Can you have a look at what current_buffer actually contains? The
> contents should start at current_buffer->text.beg + 1153, after the gap,
> an we're particularly interested in the last few bytes and the bytes
> around PT.
>
> So can you try
>
> p current_buffer->pt
> p *XSTRING(current_buffer->name_)
> p current_buffer->beg + 1153
> p current_buffer->beg + 1153 + 31770 - 64
>
> Thanks!
Also, is it possible you used quit (C-g) shortly before the crash happened?
My current theory is that the code in adjust_intervals_for_insertion
calls Fmemq and Fassq, but should call memq_no_quit and assq_no_quit.
The former functions sometimes (rarely) signal a quit, which aborts the
execution of the current function and might leave the interval tree in
an inconsistent state.
The function is entered with Vinhibit_quit = Qnil, so if the quit flag
is set, we might quit during the Fmemq or Fassq calls, and then fail to
adjust the length of the intervals, resulting in a broken interval tree.
This would be a bug in both the master and feature/igc branches; my
guess is that a tiny race condition which never happened on the master
branch became a lot more likely with MPS with its comparatively huge
pause-time.
I've so far been unable to reproduce this, but it seems to make sense to
me that no quitting should be allowed between the point at which we
modify Z and the point at which the interval tree has been updated to
reflect this change.
Pip
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Sun, 03 Aug 2025 14:52:02 GMT) Full text and rfc822 format available.Message #50 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Pip Cet <pipcet <at> protonmail.com> Cc: Óscar Fuentes <oscarfv <at> eclipso.eu>, Eli Zaretskii <eliz <at> gnu.org>, 79131 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com> Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Sun, 03 Aug 2025 16:50:53 +0200
Pip Cet <pipcet <at> protonmail.com> writes: > My current theory is that the code in adjust_intervals_for_insertion > calls Fmemq and Fassq, but should call memq_no_quit and assq_no_quit. Boah, excellent!
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Sun, 03 Aug 2025 14:59:02 GMT) Full text and rfc822 format available.Message #53 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Óscar Fuentes <oscarfv <at> eclipso.eu> Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 79131 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com> Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Sun, 03 Aug 2025 14:58:34 +0000
Óscar Fuentes <oscarfv <at> eclipso.eu> writes: > Pip Cet <pipcet <at> protonmail.com> writes: > >> So can you try >> >> p current_buffer->pt > > (gdb) fr 13 > #13 0x000055e77414774b in Fadd_text_properties (start=0x1f06a, end=0x1f07a, properties=<optimized out>, > object=0x0) at ../../emacs/src/textprop.c:1308 > 1308 return add_text_properties_1 (start, end, properties, object, > (gdb) p current_buffer->pt > $1 = 5961 > >> p *XSTRING(current_buffer->name_) > > (gdb) p *XSTRING(current_buffer->name_) > No symbol "XSTRING" in current context. Can you tell us more about the buffer, though? It was a treesitter-mode buffer that changed before the crash and contained about 32K of text? > (gdb) p current_buffer->text->beg + 1153 + 31770 > $6 = (unsigned char *) 0x55e77e16001b > > shows the last 22 characters of the buffer without garbage at the end. Oh. I messed up there; the buffer contained 31774 characters, but more bytes than that sice some of the characters were non-ASCII. > Probably you are right and this is not a MPS-related crash. I think it's a bug flushed out by the way that MPS interrupts Emacs at "random" points and does some work, making it much more likely to hit C-g in tight loops which don't really expect Vquit_flag to be set. But I'll wait for others to weigh in; maybe my theory is obviously incorrect. My lesson so far is to keep running with a non-zero pause time, even though I find a pause time of 0.0 works better for me. Pip
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Sun, 03 Aug 2025 15:11:02 GMT) Full text and rfc822 format available.Message #56 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Pip Cet <pipcet <at> protonmail.com> Cc: Óscar Fuentes <oscarfv <at> eclipso.eu>, Eli Zaretskii <eliz <at> gnu.org>, 79131 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com> Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Sun, 03 Aug 2025 17:10:25 +0200
Pip Cet <pipcet <at> protonmail.com> writes: > But I'll wait for others to weigh in; maybe my theory is obviously > incorrect. I think the memq thing is definitely a bug.
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Sun, 03 Aug 2025 15:36:03 GMT) Full text and rfc822 format available.Message #59 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Óscar Fuentes <oscarfv <at> eclipso.eu> To: Pip Cet <pipcet <at> protonmail.com> Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 79131 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com> Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Sun, 03 Aug 2025 17:35:40 +0200
Pip Cet <pipcet <at> protonmail.com> writes: > Can you tell us more about the buffer, though? It was a treesitter-mode > buffer that changed before the crash and contained about 32K of text? Yes, yes and yes. >> (gdb) p current_buffer->text->beg + 1153 + 31770 >> $6 = (unsigned char *) 0x55e77e16001b >> >> shows the last 22 characters of the buffer without garbage at the end. > > Oh. I messed up there; the buffer contained 31774 characters, but more > bytes than that sice some of the characters were non-ASCII. The buffer contains non-ASCII characters. >> Probably you are right and this is not a MPS-related crash. > > I think it's a bug flushed out by the way that MPS interrupts Emacs at > "random" points and does some work, making it much more likely to hit > C-g in tight loops which don't really expect Vquit_flag to be set. About what you asked elsewhere, I think I didn't press C-g, but at this point I'm very far from certain, so don't discard that hypothesis. > But I'll wait for others to weigh in; maybe my theory is obviously > incorrect. > > My lesson so far is to keep running with a non-zero pause time, even > though I find a pause time of 0.0 works better for me.
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Sun, 03 Aug 2025 15:48:02 GMT) Full text and rfc822 format available.Message #62 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Óscar Fuentes <oscarfv <at> eclipso.eu>, Eli Zaretskii <eliz <at> gnu.org>, 79131 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com> Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Sun, 03 Aug 2025 15:47:43 +0000
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes: > Pip Cet <pipcet <at> protonmail.com> writes: > >> But I'll wait for others to weigh in; maybe my theory is obviously >> incorrect. > > I think the memq thing is definitely a bug. Unfortunately, while Fmemq and Fassq are easy to fix, Fget can also quit (if overriding-plist-environment is in use), and that's used in a few places here. Do we need get_no_quit? Pip
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Sun, 03 Aug 2025 16:03:01 GMT) Full text and rfc822 format available.Message #65 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Pip Cet <pipcet <at> protonmail.com> Cc: gerd.moellmann <at> gmail.com, oscarfv <at> eclipso.eu, casouri <at> gmail.com, 79131 <at> debbugs.gnu.org Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Sun, 03 Aug 2025 19:01:24 +0300
> Date: Sun, 03 Aug 2025 15:47:43 +0000 > From: Pip Cet <pipcet <at> protonmail.com> > Cc: Óscar Fuentes <oscarfv <at> eclipso.eu>, Eli Zaretskii <eliz <at> gnu.org>, Yuan Fu <casouri <at> gmail.com>, 79131 <at> debbugs.gnu.org > > Gerd Möllmann <gerd.moellmann <at> gmail.com> writes: > > > Pip Cet <pipcet <at> protonmail.com> writes: > > > >> But I'll wait for others to weigh in; maybe my theory is obviously > >> incorrect. > > > > I think the memq thing is definitely a bug. > > Unfortunately, while Fmemq and Fassq are easy to fix, Fget can also quit > (if overriding-plist-environment is in use), and that's used in a few > places here. Do we need get_no_quit? Maybe we should inhibit_igc instead (if we don't already)? Otherwise, we'd need to have those _no_quit thingies all over the place. That way lies madness, IMNSHO. One cannot expect realistically the Emacs Lisp machine top be in interruptible state at all times. Even if we could, who will enforce all those tricky subtleties, when most of our patches are not even reviewed seriously?
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Sun, 03 Aug 2025 16:18:02 GMT) Full text and rfc822 format available.Message #68 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: oscarfv <at> eclipso.eu, Pip Cet <pipcet <at> protonmail.com>, 79131 <at> debbugs.gnu.org, casouri <at> gmail.com Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Sun, 03 Aug 2025 18:17:17 +0200
Eli Zaretskii <eliz <at> gnu.org> writes: >> Date: Sun, 03 Aug 2025 15:47:43 +0000 >> From: Pip Cet <pipcet <at> protonmail.com> >> Cc: Óscar Fuentes <oscarfv <at> eclipso.eu>, Eli Zaretskii <eliz <at> gnu.org>, Yuan Fu <casouri <at> gmail.com>, 79131 <at> debbugs.gnu.org >> >> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes: >> >> > Pip Cet <pipcet <at> protonmail.com> writes: >> > >> >> But I'll wait for others to weigh in; maybe my theory is obviously >> >> incorrect. >> > >> > I think the memq thing is definitely a bug. >> >> Unfortunately, while Fmemq and Fassq are easy to fix, Fget can also quit >> (if overriding-plist-environment is in use), and that's used in a few >> places here. Do we need get_no_quit? > > Maybe we should inhibit_igc instead (if we don't already)? Otherwise, You mean inhibit-quit?
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Sun, 03 Aug 2025 19:02:02 GMT) Full text and rfc822 format available.Message #71 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: oscarfv <at> eclipso.eu, pipcet <at> protonmail.com, 79131 <at> debbugs.gnu.org, casouri <at> gmail.com Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Sun, 03 Aug 2025 22:00:56 +0300
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com> > Cc: Pip Cet <pipcet <at> protonmail.com>, oscarfv <at> eclipso.eu, > casouri <at> gmail.com, 79131 <at> debbugs.gnu.org > Date: Sun, 03 Aug 2025 18:17:17 +0200 > > Eli Zaretskii <eliz <at> gnu.org> writes: > > >> Date: Sun, 03 Aug 2025 15:47:43 +0000 > >> From: Pip Cet <pipcet <at> protonmail.com> > >> Cc: Óscar Fuentes <oscarfv <at> eclipso.eu>, Eli Zaretskii <eliz <at> gnu.org>, Yuan Fu <casouri <at> gmail.com>, 79131 <at> debbugs.gnu.org > >> > >> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes: > >> > >> > Pip Cet <pipcet <at> protonmail.com> writes: > >> > > >> >> But I'll wait for others to weigh in; maybe my theory is obviously > >> >> incorrect. > >> > > >> > I think the memq thing is definitely a bug. > >> > >> Unfortunately, while Fmemq and Fassq are easy to fix, Fget can also quit > >> (if overriding-plist-environment is in use), and that's used in a few > >> places here. Do we need get_no_quit? > > > > Maybe we should inhibit_igc instead (if we don't already)? Otherwise, > > You mean inhibit-quit? No, I mean prevent MPS from interrupting a given short sequence of code with GC.
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Thu, 07 Aug 2025 17:59:02 GMT) Full text and rfc822 format available.Message #74 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, oscarfv <at> eclipso.eu, casouri <at> gmail.com, 79131 <at> debbugs.gnu.org Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Thu, 07 Aug 2025 17:58:22 +0000
"Eli Zaretskii" <eliz <at> gnu.org> writes: >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com> >> Cc: Pip Cet <pipcet <at> protonmail.com>, oscarfv <at> eclipso.eu, >> casouri <at> gmail.com, 79131 <at> debbugs.gnu.org >> Date: Sun, 03 Aug 2025 18:17:17 +0200 >> >> Eli Zaretskii <eliz <at> gnu.org> writes: >> >> >> Date: Sun, 03 Aug 2025 15:47:43 +0000 >> >> From: Pip Cet <pipcet <at> protonmail.com> >> >> Cc: Óscar Fuentes <oscarfv <at> eclipso.eu>, Eli Zaretskii <eliz <at> gnu.org>, Yuan Fu <casouri <at> gmail.com>, 79131 <at> debbugs.gnu.org >> >> >> >> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes: >> >> >> >> > Pip Cet <pipcet <at> protonmail.com> writes: >> >> > >> >> >> But I'll wait for others to weigh in; maybe my theory is obviously >> >> >> incorrect. >> >> > >> >> > I think the memq thing is definitely a bug. >> >> >> >> Unfortunately, while Fmemq and Fassq are easy to fix, Fget can also quit >> >> (if overriding-plist-environment is in use), and that's used in a few >> >> places here. Do we need get_no_quit? >> > >> > Maybe we should inhibit_igc instead (if we don't already)? Otherwise, >> >> You mean inhibit-quit? > > No, I mean prevent MPS from interrupting a given short sequence of > code with GC. I fail to see how that would work in this case, sorry. What makes this bug more likely on MPS (it exists on both branches, if it is as I described) is the existence of memory barriers, not the start of a GC cycle (which we could, in theory, stop, though we really shouldn't). So, if I'm right, I'm afraid we're going to have to go with _no_quit versions for now, or abuse the unwind-protect machinery. Using inhibit_quit would work for some quits, and possibly all of them, but I'd have to read the code again to be sure. Pip
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Thu, 07 Aug 2025 18:49:02 GMT) Full text and rfc822 format available.Message #77 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Pip Cet <pipcet <at> protonmail.com> Cc: gerd.moellmann <at> gmail.com, oscarfv <at> eclipso.eu, casouri <at> gmail.com, 79131 <at> debbugs.gnu.org Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Thu, 07 Aug 2025 21:48:24 +0300
> Date: Thu, 07 Aug 2025 17:58:22 +0000 > From: Pip Cet <pipcet <at> protonmail.com> > Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, oscarfv <at> eclipso.eu, casouri <at> gmail.com, 79131 <at> debbugs.gnu.org > > "Eli Zaretskii" <eliz <at> gnu.org> writes: > > >> >> Unfortunately, while Fmemq and Fassq are easy to fix, Fget can also quit > >> >> (if overriding-plist-environment is in use), and that's used in a few > >> >> places here. Do we need get_no_quit? > >> > > >> > Maybe we should inhibit_igc instead (if we don't already)? Otherwise, > >> > >> You mean inhibit-quit? > > > > No, I mean prevent MPS from interrupting a given short sequence of > > code with GC. > > I fail to see how that would work in this case, sorry. What makes this > bug more likely on MPS (it exists on both branches, if it is as I > described) is the existence of memory barriers, not the start of a GC > cycle (which we could, in theory, stop, though we really shouldn't). You were talking about Fmemq and Fassq vs memq_no_quit and assq_no_quit, and that the former could leave the intervals in inconsistent state. What do memory barriers have to do with that? The no-quit versions don't disable memory barriers, do they? Or what am I missing?
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Fri, 08 Aug 2025 04:38:02 GMT) Full text and rfc822 format available.Message #80 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: oscarfv <at> eclipso.eu, Pip Cet <pipcet <at> protonmail.com>, 79131 <at> debbugs.gnu.org, casouri <at> gmail.com Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Fri, 08 Aug 2025 06:37:11 +0200
Eli Zaretskii <eliz <at> gnu.org> writes: >> Date: Thu, 07 Aug 2025 17:58:22 +0000 >> From: Pip Cet <pipcet <at> protonmail.com> >> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, oscarfv <at> eclipso.eu, >> casouri <at> gmail.com, 79131 <at> debbugs.gnu.org >> >> "Eli Zaretskii" <eliz <at> gnu.org> writes: >> >> >> >> Unfortunately, while Fmemq and Fassq are easy to fix, Fget can also quit >> >> >> (if overriding-plist-environment is in use), and that's used in a few >> >> >> places here. Do we need get_no_quit? >> >> > >> >> > Maybe we should inhibit_igc instead (if we don't already)? Otherwise, >> >> >> >> You mean inhibit-quit? >> > >> > No, I mean prevent MPS from interrupting a given short sequence of >> > code with GC. >> >> I fail to see how that would work in this case, sorry. What makes this >> bug more likely on MPS (it exists on both branches, if it is as I >> described) is the existence of memory barriers, not the start of a GC >> cycle (which we could, in theory, stop, though we really shouldn't). > > You were talking about Fmemq and Fassq vs memq_no_quit and > assq_no_quit, and that the former could leave the intervals in > inconsistent state. What do memory barriers have to do with that? > The no-quit versions don't disable memory barriers, do they? > > Or what am I missing? While an algorithm is working on tree, the tree may temporarily become inconsisten. Quitting out of the algorithm where that is the case is a no-go.
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Fri, 08 Aug 2025 05:44:02 GMT) Full text and rfc822 format available.Message #83 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: oscarfv <at> eclipso.eu, Pip Cet <pipcet <at> protonmail.com>, 79131 <at> debbugs.gnu.org, casouri <at> gmail.com Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Fri, 08 Aug 2025 07:43:31 +0200
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes: > Eli Zaretskii <eliz <at> gnu.org> writes: > >>> Date: Thu, 07 Aug 2025 17:58:22 +0000 >>> From: Pip Cet <pipcet <at> protonmail.com> >>> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, oscarfv <at> eclipso.eu, >>> casouri <at> gmail.com, 79131 <at> debbugs.gnu.org >>> >>> "Eli Zaretskii" <eliz <at> gnu.org> writes: >>> >>> >> >> Unfortunately, while Fmemq and Fassq are easy to fix, Fget can also quit >>> >> >> (if overriding-plist-environment is in use), and that's used in a few >>> >> >> places here. Do we need get_no_quit? >>> >> > >>> >> > Maybe we should inhibit_igc instead (if we don't already)? Otherwise, >>> >> >>> >> You mean inhibit-quit? >>> > >>> > No, I mean prevent MPS from interrupting a given short sequence of >>> > code with GC. >>> >>> I fail to see how that would work in this case, sorry. What makes this >>> bug more likely on MPS (it exists on both branches, if it is as I >>> described) is the existence of memory barriers, not the start of a GC >>> cycle (which we could, in theory, stop, though we really shouldn't). >> >> You were talking about Fmemq and Fassq vs memq_no_quit and >> assq_no_quit, and that the former could leave the intervals in >> inconsistent state. What do memory barriers have to do with that? >> The no-quit versions don't disable memory barriers, do they? >> >> Or what am I missing? > > While an algorithm is working on tree, the tree may temporarily become > inconsisten. Quitting out of the algorithm where that is the case is a > no-go. Maybe one could somewhere communicate, as a rule of thumb: When you write a C function that modifies a data structure, you must not call funcrtions that can signal an error or quit while the data structure is in an inconsistent state. Note that all C functions beginning
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Fri, 08 Aug 2025 06:20:01 GMT) Full text and rfc822 format available.Message #86 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: oscarfv <at> eclipso.eu, pipcet <at> protonmail.com, 79131 <at> debbugs.gnu.org, casouri <at> gmail.com Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Fri, 08 Aug 2025 09:18:48 +0300
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com> > Cc: Pip Cet <pipcet <at> protonmail.com>, oscarfv <at> eclipso.eu, > casouri <at> gmail.com, 79131 <at> debbugs.gnu.org > Date: Fri, 08 Aug 2025 06:37:11 +0200 > > Eli Zaretskii <eliz <at> gnu.org> writes: > > >> Date: Thu, 07 Aug 2025 17:58:22 +0000 > >> From: Pip Cet <pipcet <at> protonmail.com> > >> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, oscarfv <at> eclipso.eu, > >> casouri <at> gmail.com, 79131 <at> debbugs.gnu.org > >> > >> "Eli Zaretskii" <eliz <at> gnu.org> writes: > >> > >> >> >> Unfortunately, while Fmemq and Fassq are easy to fix, Fget can also quit > >> >> >> (if overriding-plist-environment is in use), and that's used in a few > >> >> >> places here. Do we need get_no_quit? > >> >> > > >> >> > Maybe we should inhibit_igc instead (if we don't already)? Otherwise, > >> >> > >> >> You mean inhibit-quit? > >> > > >> > No, I mean prevent MPS from interrupting a given short sequence of > >> > code with GC. > >> > >> I fail to see how that would work in this case, sorry. What makes this > >> bug more likely on MPS (it exists on both branches, if it is as I > >> described) is the existence of memory barriers, not the start of a GC > >> cycle (which we could, in theory, stop, though we really shouldn't). > > > > You were talking about Fmemq and Fassq vs memq_no_quit and > > assq_no_quit, and that the former could leave the intervals in > > inconsistent state. What do memory barriers have to do with that? > > The no-quit versions don't disable memory barriers, do they? > > > > Or what am I missing? > > While an algorithm is working on tree, the tree may temporarily become > inconsisten. Quitting out of the algorithm where that is the case is a > no-go. Is that related to igc in some way? The discussion was about igc making this happen, or making it happen more frequently. What you say seem to be unrelated.
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Fri, 08 Aug 2025 06:26:02 GMT) Full text and rfc822 format available.Message #89 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: oscarfv <at> eclipso.eu, pipcet <at> protonmail.com, 79131 <at> debbugs.gnu.org, casouri <at> gmail.com Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Fri, 08 Aug 2025 08:25:04 +0200
Eli Zaretskii <eliz <at> gnu.org> writes: >> While an algorithm is working on tree, the tree may temporarily become >> inconsisten. Quitting out of the algorithm where that is the case is a >> no-go. > > Is that related to igc in some way? No. > The discussion was about igc making this happen, or making it happen > more frequently. What you say seem to be unrelated. More frequently was a hypotheses of Pip, as a side note.
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Fri, 08 Aug 2025 07:05:02 GMT) Full text and rfc822 format available.Message #92 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: oscarfv <at> eclipso.eu, pipcet <at> protonmail.com, 79131 <at> debbugs.gnu.org, casouri <at> gmail.com Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Fri, 08 Aug 2025 10:04:37 +0300
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com> > Cc: pipcet <at> protonmail.com, oscarfv <at> eclipso.eu, casouri <at> gmail.com, > 79131 <at> debbugs.gnu.org > Date: Fri, 08 Aug 2025 08:25:04 +0200 > > Eli Zaretskii <eliz <at> gnu.org> writes: > > >> While an algorithm is working on tree, the tree may temporarily become > >> inconsisten. Quitting out of the algorithm where that is the case is a > >> no-go. > > > > Is that related to igc in some way? > > No. > > > The discussion was about igc making this happen, or making it happen > > more frequently. What you say seem to be unrelated. > > More frequently was a hypotheses of Pip, as a side note. I responded only to that side note.
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Fri, 08 Aug 2025 07:11:02 GMT) Full text and rfc822 format available.Message #95 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: oscarfv <at> eclipso.eu, pipcet <at> protonmail.com, 79131 <at> debbugs.gnu.org, casouri <at> gmail.com Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Fri, 08 Aug 2025 09:10:07 +0200
Eli Zaretskii <eliz <at> gnu.org> writes: >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com> >> Cc: pipcet <at> protonmail.com, oscarfv <at> eclipso.eu, casouri <at> gmail.com, >> 79131 <at> debbugs.gnu.org >> Date: Fri, 08 Aug 2025 08:25:04 +0200 >> >> Eli Zaretskii <eliz <at> gnu.org> writes: >> >> >> While an algorithm is working on tree, the tree may temporarily become >> >> inconsisten. Quitting out of the algorithm where that is the case is a >> >> no-go. >> > >> > Is that related to igc in some way? >> >> No. >> >> > The discussion was about igc making this happen, or making it happen >> > more frequently. What you say seem to be unrelated. >> >> More frequently was a hypotheses of Pip, as a side note. > > I responded only to that side note. Then Ipropose to go with whatever Pip finds out to be the best: either specbind or *_no_quit.
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Fri, 08 Aug 2025 10:20:02 GMT) Full text and rfc822 format available.Message #98 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: oscarfv <at> eclipso.eu, pipcet <at> protonmail.com, 79131 <at> debbugs.gnu.org, casouri <at> gmail.com Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Fri, 08 Aug 2025 13:19:46 +0300
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com> > Cc: pipcet <at> protonmail.com, oscarfv <at> eclipso.eu, casouri <at> gmail.com, > 79131 <at> debbugs.gnu.org > Date: Fri, 08 Aug 2025 09:10:07 +0200 > > Eli Zaretskii <eliz <at> gnu.org> writes: > > >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com> > >> Cc: pipcet <at> protonmail.com, oscarfv <at> eclipso.eu, casouri <at> gmail.com, > >> 79131 <at> debbugs.gnu.org > >> Date: Fri, 08 Aug 2025 08:25:04 +0200 > >> > >> Eli Zaretskii <eliz <at> gnu.org> writes: > >> > >> >> While an algorithm is working on tree, the tree may temporarily become > >> >> inconsisten. Quitting out of the algorithm where that is the case is a > >> >> no-go. > >> > > >> > Is that related to igc in some way? > >> > >> No. > >> > >> > The discussion was about igc making this happen, or making it happen > >> > more frequently. What you say seem to be unrelated. > >> > >> More frequently was a hypotheses of Pip, as a side note. > > > > I responded only to that side note. > > Then Ipropose to go with whatever Pip finds out to be the best: either > specbind or *_no_quit. Before we do, I'd like to see the actual places where we currently call functions which can quit, while intervals are in inconsistent state. I don't think those places were identified (if I missed that, please point me to the message where they were identified). Thanks.
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Fri, 08 Aug 2025 12:11:01 GMT) Full text and rfc822 format available.Message #101 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: gerd.moellmann <at> gmail.com, oscarfv <at> eclipso.eu, casouri <at> gmail.com, 79131 <at> debbugs.gnu.org Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Fri, 08 Aug 2025 12:10:14 +0000
"Eli Zaretskii" <eliz <at> gnu.org> writes: >> Date: Thu, 07 Aug 2025 17:58:22 +0000 >> From: Pip Cet <pipcet <at> protonmail.com> >> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, oscarfv <at> eclipso.eu, casouri <at> gmail.com, 79131 <at> debbugs.gnu.org >> >> "Eli Zaretskii" <eliz <at> gnu.org> writes: >> >> >> >> Unfortunately, while Fmemq and Fassq are easy to fix, Fget can also quit >> >> >> (if overriding-plist-environment is in use), and that's used in a few >> >> >> places here. Do we need get_no_quit? >> >> > >> >> > Maybe we should inhibit_igc instead (if we don't already)? Otherwise, >> >> >> >> You mean inhibit-quit? >> > >> > No, I mean prevent MPS from interrupting a given short sequence of >> > code with GC. >> >> I fail to see how that would work in this case, sorry. What makes this >> bug more likely on MPS (it exists on both branches, if it is as I >> described) is the existence of memory barriers, not the start of a GC >> cycle (which we could, in theory, stop, though we really shouldn't). > > You were talking about Fmemq and Fassq vs memq_no_quit and > assq_no_quit, and that the former could leave the intervals in > inconsistent state. That is correct. > What do memory barriers have to do with that? As I said, I think they make this bug scenario more likely. When MPS hits a memory barrier, it doesn't just work to clear the memory barrier, but (by default) it performs some extra work to make progress on the GC. It is these interruptions I was talking about. We can't prevent them, because they're what makes MPS work. We can reduce the pause time, which reduces or removes the extra work done by MPS in this situation, but I don't think we want to do that just to reduce the likelihood of running into known and fixable bugs. > The no-quit versions don't disable memory barriers, do they? No, they just prevent quitting out of the interval management functions while the state is inconsistent (in particular, after the buffer text size changed and before the interval tree size was updated to reflect that). So I'm still failing to see what "inhibit_igc" would even do, and I don't think it would help in this case. Pip
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Fri, 08 Aug 2025 12:40:01 GMT) Full text and rfc822 format available.Message #104 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Pip Cet <pipcet <at> protonmail.com> Cc: gerd.moellmann <at> gmail.com, oscarfv <at> eclipso.eu, casouri <at> gmail.com, 79131 <at> debbugs.gnu.org Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Fri, 08 Aug 2025 15:39:33 +0300
> Date: Fri, 08 Aug 2025 12:10:14 +0000 > From: Pip Cet <pipcet <at> protonmail.com> > Cc: gerd.moellmann <at> gmail.com, oscarfv <at> eclipso.eu, casouri <at> gmail.com, 79131 <at> debbugs.gnu.org > > "Eli Zaretskii" <eliz <at> gnu.org> writes: > > >> Date: Thu, 07 Aug 2025 17:58:22 +0000 > >> From: Pip Cet <pipcet <at> protonmail.com> > >> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, oscarfv <at> eclipso.eu, casouri <at> gmail.com, 79131 <at> debbugs.gnu.org > >> > >> "Eli Zaretskii" <eliz <at> gnu.org> writes: > >> > >> >> >> Unfortunately, while Fmemq and Fassq are easy to fix, Fget can also quit > >> >> >> (if overriding-plist-environment is in use), and that's used in a few > >> >> >> places here. Do we need get_no_quit? > >> >> > > >> >> > Maybe we should inhibit_igc instead (if we don't already)? Otherwise, > >> >> > >> >> You mean inhibit-quit? > >> > > >> > No, I mean prevent MPS from interrupting a given short sequence of > >> > code with GC. > >> > >> I fail to see how that would work in this case, sorry. What makes this > >> bug more likely on MPS (it exists on both branches, if it is as I > >> described) is the existence of memory barriers, not the start of a GC > >> cycle (which we could, in theory, stop, though we really shouldn't). > > > > You were talking about Fmemq and Fassq vs memq_no_quit and > > assq_no_quit, and that the former could leave the intervals in > > inconsistent state. > > That is correct. > > > What do memory barriers have to do with that? > > As I said, I think they make this bug scenario more likely. When MPS > hits a memory barrier, it doesn't just work to clear the memory barrier, > but (by default) it performs some extra work to make progress on the GC. > > It is these interruptions I was talking about. We can't prevent them, > because they're what makes MPS work. We can reduce the pause time, which > reduces or removes the extra work done by MPS in this situation, but I > don't think we want to do that just to reduce the likelihood of running > into known and fixable bugs. > > > The no-quit versions don't disable memory barriers, do they? > > No, they just prevent quitting out of the interval management functions > while the state is inconsistent (in particular, after the buffer text > size changed and before the interval tree size was updated to reflect > that). > > So I'm still failing to see what "inhibit_igc" would even do, and I > don't think it would help in this case. As usual, these discussions are quickly becoming theoretical and disconnected from reality, and we are talking past each other. To make this useful, please point to specific places where the problematic functions (Fmemq etc.) are called while the intervals could be in inconsistent state, and let's take it from there.
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Fri, 08 Aug 2025 13:09:02 GMT) Full text and rfc822 format available.Message #107 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, oscarfv <at> eclipso.eu, casouri <at> gmail.com, 79131 <at> debbugs.gnu.org Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Fri, 08 Aug 2025 13:08:12 +0000
"Eli Zaretskii" <eliz <at> gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: pipcet <at> protonmail.com, oscarfv <at> eclipso.eu, casouri <at> gmail.com,
>> 79131 <at> debbugs.gnu.org
>> Date: Fri, 08 Aug 2025 09:10:07 +0200
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> >> Cc: pipcet <at> protonmail.com, oscarfv <at> eclipso.eu, casouri <at> gmail.com,
>> >> 79131 <at> debbugs.gnu.org
>> >> Date: Fri, 08 Aug 2025 08:25:04 +0200
>> >>
>> >> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >>
>> >> >> While an algorithm is working on tree, the tree may temporarily become
>> >> >> inconsisten. Quitting out of the algorithm where that is the case is a
>> >> >> no-go.
>> >> >
>> >> > Is that related to igc in some way?
>> >>
>> >> No.
>> >>
>> >> > The discussion was about igc making this happen, or making it happen
>> >> > more frequently. What you say seem to be unrelated.
>> >>
>> >> More frequently was a hypotheses of Pip, as a side note.
>> >
>> > I responded only to that side note.
>>
>> Then Ipropose to go with whatever Pip finds out to be the best: either
>> specbind or *_no_quit.
>
> Before we do, I'd like to see the actual places where we currently
> call functions which can quit, while intervals are in inconsistent
> state.
The explicit calls to Fmemq in intervals.c would be two such places:
static INTERVAL
adjust_intervals_for_insertion (INTERVAL tree,
ptrdiff_t position, ptrdiff_t length)
{
....
/* Does any actual property pose an actual problem? We break
the loop if we find a nonsticky property. */
for (; CONSP (tail); tail = Fcdr (XCDR (tail)))
{
Lisp_Object prop, tmp;
prop = XCAR (tail);
/* Is this particular property front-sticky? */
if (CONSP (front) && ! NILP (Fmemq (prop, front))) <--- quit happens here
continue;
/* Is this particular property rear-nonsticky? */
if (CONSP (rear) && ! NILP (Fmemq (prop, rear)))
break;
....
}
/* If we are positioned between intervals, check the stickiness of
both of them. We have to do this too, if we are at BEG or Z. */
if (position == i->position || eobp)
{
...
for (temp = prev ? prev : i; temp; temp = INTERVAL_PARENT_OR_NULL (temp))
{
temp->total_length += length; <--- adjustment happens here
...
}
else
{
for (temp = i; temp; temp = INTERVAL_PARENT_OR_NULL (temp))
{
temp->total_length += length;
...
}
}
return tree;
Here's the case for insertion:
Intervals are in an inconsistent state from the point where Z is
increased in insert_from_gap_1 until the total length of the root
interval is increased to match it in adjust_intervals_for_insertion
(both of these functions are called from insert_from_gap).
So adjust_intervals_for_insertion must not call any function that can
quit (if it does so before the total length is updated, intervals will
be in an inconsistent state. If it does so afterwards, we'll fail to
adjust point after the insertion).
But it calls Fmemq and Fassq, both directly and via TMEM and textget, in
certain circumstances. Those calls happen before total_length is
adjusted. My gdb session indicates that Vinhibit_quit is nil when this
function is reached for a normal character insertion.
Fmemq and Fassq sometimes quit, though they will also sometimes ignore
the quit flag and return normally, because of the rather complicated
logic in FOR_EACH_TAIL_INTERNAL; my guess from looking at the code is
that we need to walk to at least the third element of a list before we
first check the quit flag.
We might be able to produce an inconsistent state by setting a
breakpoint in gdb and setting Vquit_flag = Qt at the wrong moment; would
that help in any way?
Pip
bug-gnu-emacs <at> gnu.org:bug#79131; Package emacs.
(Fri, 08 Aug 2025 13:35:01 GMT) Full text and rfc822 format available.Message #110 received at 79131 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Pip Cet <pipcet <at> protonmail.com> Cc: gerd.moellmann <at> gmail.com, oscarfv <at> eclipso.eu, casouri <at> gmail.com, 79131 <at> debbugs.gnu.org Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Date: Fri, 08 Aug 2025 16:34:04 +0300
> Date: Fri, 08 Aug 2025 13:08:12 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, oscarfv <at> eclipso.eu, casouri <at> gmail.com, 79131 <at> debbugs.gnu.org
>
> "Eli Zaretskii" <eliz <at> gnu.org> writes:
>
> >> Then Ipropose to go with whatever Pip finds out to be the best: either
> >> specbind or *_no_quit.
> >
> > Before we do, I'd like to see the actual places where we currently
> > call functions which can quit, while intervals are in inconsistent
> > state.
>
> The explicit calls to Fmemq in intervals.c would be two such places:
>
> static INTERVAL
> adjust_intervals_for_insertion (INTERVAL tree,
> ptrdiff_t position, ptrdiff_t length)
> {
> ....
> /* Does any actual property pose an actual problem? We break
> the loop if we find a nonsticky property. */
> for (; CONSP (tail); tail = Fcdr (XCDR (tail)))
> {
> Lisp_Object prop, tmp;
> prop = XCAR (tail);
>
> /* Is this particular property front-sticky? */
> if (CONSP (front) && ! NILP (Fmemq (prop, front))) <--- quit happens here
> continue;
>
> /* Is this particular property rear-nonsticky? */
> if (CONSP (rear) && ! NILP (Fmemq (prop, rear)))
> break;
> ....
> }
>
> /* If we are positioned between intervals, check the stickiness of
> both of them. We have to do this too, if we are at BEG or Z. */
> if (position == i->position || eobp)
> {
> ...
> for (temp = prev ? prev : i; temp; temp = INTERVAL_PARENT_OR_NULL (temp))
> {
> temp->total_length += length; <--- adjustment happens here
> ...
> }
> else
> {
> for (temp = i; temp; temp = INTERVAL_PARENT_OR_NULL (temp))
> {
> temp->total_length += length;
> ...
> }
> }
>
> return tree;
>
>
> Here's the case for insertion:
>
> Intervals are in an inconsistent state from the point where Z is
> increased in insert_from_gap_1 until the total length of the root
> interval is increased to match it in adjust_intervals_for_insertion
> (both of these functions are called from insert_from_gap).
>
> So adjust_intervals_for_insertion must not call any function that can
> quit (if it does so before the total length is updated, intervals will
> be in an inconsistent state. If it does so afterwards, we'll fail to
> adjust point after the insertion).
>
> But it calls Fmemq and Fassq, both directly and via TMEM and textget, in
> certain circumstances. Those calls happen before total_length is
> adjusted. My gdb session indicates that Vinhibit_quit is nil when this
> function is reached for a normal character insertion.
>
> Fmemq and Fassq sometimes quit, though they will also sometimes ignore
> the quit flag and return normally, because of the rather complicated
> logic in FOR_EACH_TAIL_INTERNAL; my guess from looking at the code is
> that we need to walk to at least the third element of a list before we
> first check the quit flag.
>
> We might be able to produce an inconsistent state by setting a
> breakpoint in gdb and setting Vquit_flag = Qt at the wrong moment; would
> that help in any way?
I think it's simpler to bind inhibit-quit non-nil inside
offset_intervals. memq_no_quit differs from Fmemq in other aspects,
and I don't see why we should risk unintended consequences to fix this
rare (if at all) problem.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.