From unknown Sun Aug 17 22:00:42 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#79131 <79131@debbugs.gnu.org> To: bug#79131 <79131@debbugs.gnu.org> Subject: Status: 31.0.50; igc: nested signal, SIGSEGV Reply-To: bug#79131 <79131@debbugs.gnu.org> Date: Mon, 18 Aug 2025 05:00:42 +0000 retitle 79131 31.0.50; igc: nested signal, SIGSEGV reassign 79131 emacs submitter 79131 =C3=93scar Fuentes severity 79131 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 30 16:19:07 2025 Received: (at submit) by debbugs.gnu.org; 30 Jul 2025 20:19:07 +0000 Received: from localhost ([127.0.0.1]:43133 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhDGT-0001rQ-JC for submit@debbugs.gnu.org; Wed, 30 Jul 2025 16:19:07 -0400 Received: from lists.gnu.org ([2001:470:142::17]:49816) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uhDGQ-0001qn-5U for submit@debbugs.gnu.org; Wed, 30 Jul 2025 16:19:04 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uhDGK-0008RM-36 for bug-gnu-emacs@gnu.org; Wed, 30 Jul 2025 16:18:56 -0400 Received: from mail.eclipso.de ([217.69.254.104]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uhDGF-0002Rj-75 for bug-gnu-emacs@gnu.org; Wed, 30 Jul 2025 16:18:55 -0400 X-ESMTP-Authenticated-User: 000D6BEA From: =?utf-8?Q?=C3=93scar_Fuentes?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclipso.de; s=mail; t=1753906726; bh=yvYwrMPyVGMzA4TKAsTAjgZrEGm3tqVU2rAkJ9XMuJ8=; h=From:To:Subject:Date:From; b=Mf7eNerTHQWLfeAJ3lEyWIwFpICnIdDAaWUrGhZEXVp7ulSSGhTEIJVgv06mgeMJj 6A61Mo4GhBBSel7e7fheKibntTnG/lKtYXSsPBMu3tjy7tUtU/fmq6LgB5Bi3exZht DR3EM+UZ22OPL3i0pXtEUAzIE8cc2jcUWCwtcNxIyWOTVVSi7E61OSsKhTsJoRIZvy 3+VXFKVgh4oVpULz8cU/rBQkONQ4PfpgO+SLFGT0KbBz/9i9rx0OvKIqsUUksO8Brf 1o8vOuPJq1lulZbQnB2N9Z8b7+lryJg7xJWNfIL/TG8WGEXfI/4wMvZFRmKaiaYtmn LTVnBTOJE9PtA== To: bug-gnu-emacs@gnu.org Subject: 31.0.50; igc: nested signal, SIGSEGV X-Debbugs-Cc: Pip Cet , Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n?= Date: Wed, 30 Jul 2025 22:18:44 +0200 Message-ID: <878qk5qvob.fsf@telefonica.net> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=217.69.254.104; envelope-from=oscarfv@eclipso.eu; helo=mail.eclipso.de X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) 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=3D, signo=3Dsign= o@entry=3D11, no_tid=3Dno_tid@entry=3D0) at ./nptl/pthread_kill.c:44 tid =3D ret =3D 0 pd =3D old_mask =3D {__val =3D {94452575465120}} ret =3D #1 0x00007f506ce9e9ff in __pthread_kill_internal (threadid=3D, signo=3D11) at ./nptl/pthread_kill.c:89 #2 0x00007f506ce49cc2 in __GI_raise (sig=3Dsig@entry=3D11) at ../sysdeps/p= osix/raise.c:26 ret =3D #3 0x000055e773f12db8 in terminate_due_to_signal (sig=3Dsig@entry=3D11, backtrace_limit=3Dbacktrace_limit@entry=3D40) at= ../../emacs/src/emacs.c:481 #4 0x000055e773f132de in handle_fatal_signal (sig=3Dsig@entry=3D11) at ../= ../emacs/src/sysdep.c:1793 #5 0x000055e773f132e5 in deliver_thread_signal (sig=3Dsig@entry=3D11, handler=3D0x55e773f132d0 ) = at ../../emacs/src/sysdep.c:1785 old_errno =3D #6 0x000055e774058dec in deliver_fatal_thread_signal (sig=3D11) at ../../e= macs/src/sysdep.c:1805 #7 handle_sigsegv (sig=3D11, siginfo=3D, arg=3D) at ../../emacs/src/sysdep.c:1943 fatal =3D #8 0x00007f506ce49df0 in () at /lib/x86_64-linux-g= nu/libc.so.6 #9 0x00007f506ce4a007 in __GI_kill () at ../sysdeps/unix/syscall-template.= S:120 #10 0x000055e774215e44 in sigHandle () #11 0x00007f506ce49df0 in () at /lib/x86_64-linux-g= nu/libc.so.6 #12 add_text_properties_1 (start=3D, start@entry=3D0x1f06a, = end=3D,=20 end@entry=3D0x1f07a, properties=3D0x7f4fe3c2acc3, object=3D0x7f4fe645cf= bd,=20 object@entry=3D0x0, set_type=3Dset_type@entry=3DTEXT_PROPERTY_REPLACE, = destructive=3Ddestructive@entry=3Dtrue) --Type for more, q to quit, c to continue without paging--c at ../../emacs/src/textprop.c:1252 i =3D 0x0 unchanged =3D s =3D 31770 len =3D 3 modified =3D first_time =3D #13 0x000055e77414774b in Fadd_text_properties (start=3D0x1f06a, end=3D0x1f07a, properties=3D, object= =3D0x0) at ../../emacs/src/textprop.c:1308 #14 Fput_text_property (start=3D0x1f06a, end=3D0x1f07a, property=3D, value=3D, object=3D0x0) at ../../emacs/src/textprop.c:1326 properties =3D #15 0x00007f505801aec2 in F747265657369742d2d666f6e742d6c6f636b2d6d61726b2d= 72616e6765732d746f2d666f6e74696679_treesit__font_lock_mark_ranges_to_fontif= y_0 () at /home/oscar/.emacs.d/eln-cache/31.0.50-3eae311e/treesit-37439c61-2c2= 08e3a.eln #16 0x000055e7740c8e8c in Ffuncall (nargs=3D2, args=3D0x7ffd6a2b0e70) at ..= /../emacs/src/eval.c:3201 count =3D {bytes =3D } val =3D #17 0x00007f505801b396 in F747265657369742d2d7072652d7265646973706c6179_tre= esit__pre_redisplay_0 () at /home/oscar/.emacs.d/eln-cache/31.0.50-3eae311e/treesit-37439c61-2c2= 08e3a.eln #18 0x000055e7740c8e8c in Ffuncall (nargs=3D2, args=3D0x7ffd6a2b0f80) at ..= /../emacs/src/eval.c:3201 count =3D {bytes =3D } val =3D #19 0x000055e7740c90e9 in funcall_nil (nargs=3D, args=3D) at ../../emacs/src/eval.c:2884 #20 0x000055e7740c643d in run_hook_with_args (nargs=3D2, args=3D0x7ffd6a2b0f80, funcall=3D0x55e7740c90e0 ) at ../../emacs/src/eval.c:3061 global_vals =3D sym =3D 0x2968c2d2eba0 val =3D 0x7f4fe52f5c83 ret =3D 0x0 #21 0x000055e7740c8e8c in Ffuncall (nargs=3D3, args=3D0x7ffd6a2b0f78) at ..= /../emacs/src/eval.c:3201 count =3D {bytes =3D } val =3D #22 0x00007f505b7c1d34 in F7265646973706c61792d2d7072652d7265646973706c6179= 2d66756e6374696f6e73_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=3Dnargs@entry=3D2, args=3Dargs@en= try=3D0x7f505ad28040) at ../../emacs/src/eval.c:3201 count =3D {bytes =3D } val =3D #24 0x000055e7740c7742 in Fapply (nargs=3D2, args=3D0x7f505ad28040) at ../.= ./emacs/src/eval.c:2830 i =3D funcall_nargs =3D funcall_args =3D 0x0 spread_arg =3D fun =3D 0x2968f6dc91d8 sa_avail =3D 16384 sa_count =3D {bytes =3D } numargs =3D retval =3D #25 0x000055e77411753a in exec_byte_code (fun=3D, args_template=3D, nargs=3D, args=3D) at ../../emacs/src/lisp.h:2306 call_nargs =3D 2 call_fun =3D count1 =3D {bytes =3D } val =3D call_args =3D 0x7f505ad28040 original_fun =3D 0x43d0 op =3D 2 type =3D targets =3D {0x55e773f17ee1 , 0x55e77411793= f , 0x55e77411793a , 0x55e7741179= 35 , 0x55e77411731d , 0x55e7741173= 1d , 0x55e7741178f7 , 0x55e7741178= b9 , 0x55e7741198e2 , 0x55e77411= 98dd , 0x55e7741198d8 , 0x55e77= 41198d3 , 0x55e774117357 , 0x55e7= 74117360 , 0x55e7741198c6 , 0x55e= 7741198e7 , 0x55e77411976e , 0x5= 5e774119769 , 0x55e774119764 , 0x= 55e77411975f , 0x55e7741172b9 , 0x= 55e7741172c0 , 0x55e774119745 , 0x= 55e774119752 , 0x55e7741196f3 , 0= x55e7741196ee , 0x55e7741196e9 , = 0x55e7741196e4 , 0x55e7741175ef ,= 0x55e7741175f0 , 0x55e774119705 = , 0x55e7741196f8 , 0x55e7741196c5 , 0x55e7741196c0 , 0x55e7741196bb , 0x55e7741196b6 , 0x55e7741173bd , 0x55e7741173c0 , 0x55e7741196d7 , 0x55e7741196ca , 0x55e774119697 , 0x55e774119692 , 0x55e77411968d , 0x55e774119688 , 0x55e774117639 , 0x55e774117640 , 0x55e7741196a9 , 0x55e77411969c , 0x55e774119273 , 0x55e7741192a7 , 0x55e774119330 , 0x55e773f17ee1 , 0x55e773f17ee1 , 0x55e773f17ee1 , 0x55e773f17ee1 , 0x55e773f17ee1 , 0x55e77411= 90c7 , 0x55e774119054 , 0x55e7741= 1900d , 0x55e774118fc6 , 0x55e774= 118f81 , 0x55e7741197ef , 0x55e77= 41197af , 0x55e774118f4f , 0x55e7= 7411984b , 0x55e774119773 , 0x55e= 774118f0f , 0x55e774118edf , 0x55= e774118e9f , 0x55e774118e62 , 0x5= 5e774118e21 , 0x55e774118dab , 0x= 55e774118d20 , 0x55e774118c8b , 0= x55e774118c5b , 0x55e774118c2b , = 0x55e774118beb , 0x55e774118bab ,= 0x55e774118b6b , 0x55e774118b27 = , 0x55e774118aed , 0x55e774118ab3 , 0x55e774118a79 , 0x55e7741189d7 , 0x55e77411897b , 0x55e774118921 , 0x55e7741188c7 , 0x55e77411886d , 0x55e774118813 , 0x55e7741187b9 , 0x55e774118761 , 0x55e774118704 , 0x55e7741186ac , 0x55e774118654 , 0x55e7741185fc , 0x55e7741185a3 , 0x55e7741184b2 , 0x55e774117689 , 0x55e774118482 , 0x55e77411844d , 0x55e7741183bd , 0x55e774118373 , 0x55e774118343 , 0x55e774118311 , 0x55e7741182df , 0x55e7741182a5 , 0x55e774118273 , 0x55e773f17ee1 , 0x55e774118241 , 0x55e77411820f , 0x55e7741181dd , 0x55e7741181ab , 0x55e774118179 , 0x55e774118149 <= exec_byte_code+4105>, 0x55e774117689 , 0x55e773f17ee1 = , 0x55e774118105 , 0x55e774118= 0d4 , 0x55e7741180a3 , 0x55e77411= 8062 , 0x55e774118021 , 0x55e7741= 17ff0 , 0x55e774117fbf , 0x55e774= 117f7e , 0x55e774117f3d , 0x55e77= 4117efc , 0x55e774117ec9 , 0x55e7= 74117e98 , 0x55e773f17ee1 , 0x= 55e77411943f , 0x55e774119615 , 0= x55e774119887 , 0x55e7741195d6 ,= 0x55e77411959a , 0x55e77411955e = , 0x55e77411949d , 0x55e774119478 , 0x55e774119712 , 0x55e77411941a , 0x55e7741193b7 , 0x55e774119382 , 0x55e77411933b , 0x55e77411921e , 0x55e7741191da , 0x55e774119190 , 0x55e774119125 , 0x55e773f17ee1 , 0x55e774117e53 , 0x55e774117e22 , 0x55e774117df1 , 0x55e774117dc0 , 0x55e774117d8f , 0x55e774117d4e , 0x55e774117d0d , 0x55e774117ccc , 0x55e774117c8b , 0x55e774117c24 , 0x55e774117be3 , 0x55e774117ba2 , 0x55e774117b71 , 0x55e774117b25 , 0x55e774117ad9 , 0x55e774117a9b , 0x55e774117a5d , 0x55e774117a22 , 0x55e77411854b , 0x55e7741184fc , 0x55e7741179b2 , 0x55e774117944 <= exec_byte_code+2052>, 0x55e773f17ee1 , 0x55e773f17e= e1 , 0x55e773f17ee1 , 0x55e= 773f17ee1 , 0x55e773f17ee1 = , 0x55e773f17ee1 , 0x55e774118ddb , 0x55e774118a33 , 0x55e774118407 , 0x55e774117873 , 0x55e77411782d , 0x55e773f17ee1 , 0x55e773f17ee1 , 0x55e7741177f4 , 0x55e774117790 , 0x55e773f17ee1 , 0x55e773f17ee1 , 0x55e773f17ee1 , 0x55e773f17= ee1 , 0x55e773f17ee1 , 0x55= e773f17ee1 , 0x55e773f17ee1 , 0x55e773f17ee1 , 0x55e774117756 } quitcounter =3D bc =3D 0x55e7742cb858 top =3D 0x7f505ad28038 pc =3D bytestr =3D vector =3D maxdepth =3D const_length =3D bytestr_length =3D vectorp =3D 0x7f506b0a53f0 max_stack =3D frame_base =3D fp =3D bytestr_data =3D rest =3D mandatory =3D nonrest =3D pushedargs =3D saved_quitcounter =3D 0 '\000' saved_vectorp =3D 0xdd98 saved_bytestr_data =3D 0x7ffd00000002 result =3D #26 0x000055e7740c8e8c in Ffuncall (nargs=3Dnargs@entry=3D2, args=3Dargs@en= try=3D0x7ffd6a2b1290) at ../../emacs/src/eval.c:3201 count =3D {bytes =3D } val =3D #27 0x000055e7740c5dbe in internal_condition_case_n (bfun=3Dbfun@entry=3D0x55e7740c8d90 , nargs=3Dnargs@entry=3D2= , args=3Dargs@entry=3D0x7ffd6a2b1290, handlers=3Dhandlers@entry=3D0x38, hfu= n=3Dhfun@entry=3D0x55e773f4e550 ) at ../../emacs/src/ev= al.c:1793 val =3D c =3D 0x55e77bd0b710 #28 0x000055e773f3bc04 in dsafe__call (inhibit_quit=3Dinhibit_quit@entry=3Dtrue, f=3D0x55e7740c8d90 , nargs=3Dnargs@entry=3D2, args=3Dargs@entry=3D0x7ffd6a2b1290) at ../../em= acs/src/xdisp.c:3106 count =3D {bytes =3D } redisplay_counter_before =3D 939536 val =3D #29 0x000055e773f6efbe in dsafe__call (inhibit_quit=3Dtrue, nargs=3D2, f=3D= , args=3D0x7ffd6a2b1290) at ../../emacs/src/xdisp.c:3094 val =3D count =3D {bytes =3D } redisplay_counter_before =3D #30 prepare_menu_bars () at ../../emacs/src/xdisp.c:14060 windows =3D all_windows =3D some_windows =3D all_windows =3D some_windows =3D windows =3D ws =3D this =3D w =3D tail =3D frame =3D f =3D w =3D tail =3D frame =3D count =3D {bytes =3D } menu_bar_hooks_run =3D sw =3D sf =3D rf =3D f =3D w =3D sw =3D sf =3D rf =3D #31 redisplay_internal () at ../../emacs/src/xdisp.c:17289 w =3D 0x7f50663eea30 sw =3D 0x7f50663eea30 fr =3D must_finish =3D match_p =3D tlbufpos =3D {charpos =3D , bytepos =3D } tlendpos =3D {charpos =3D , bytepos =3D } number_of_visible_frames =3D sf =3D polling_stopped_here =3D tail =3D frame =3D hscroll_retries =3D garbaged_frame_retries =3D consider_all_windows_p =3D update_miniwindow_p =3D count =3D {bytes =3D } retry =3D previous_frame =3D current_matrices_cleared =3D new_count =3D #32 0x000055e773f70ee5 in redisplay_preserve_echo_area (from_where=3Dfrom_w= here@entry=3D8) at ../../emacs/src/xdisp.c:18050 count =3D {bytes =3D } #33 0x000055e77404e811 in detect_input_pending_run_timers (do_display=3Ddo_= display@entry=3Dtrue) at ../../emacs/src/keyboard.c:11765 old_timers_run =3D #34 0x000055e77412e143 in wait_reading_process_output (time_limit=3Dtime_limit@entry=3D30, nsecs=3Dnsecs@entry=3D0, read_kbd= =3Dread_kbd@entry=3D-1, do_display=3Ddo_display@entry=3Dtrue, wait_for_cell= =3Dwait_for_cell@entry=3D0x0, wait_proc=3Dwait_proc@entry=3D0x0, just_wait_= proc=3D0) at ../../emacs/src/process.c:5863 leave =3D false process_skipped =3D wrapped =3D channel_start =3D child_fd =3D last_read_channel =3D 18 channel =3D nfds =3D Available =3D {fds_bits =3D {103483688, 0 }} Writeok =3D {fds_bits =3D {0 }} check_write =3D check_delay =3D no_avail =3D false xerrno =3D 11 proc =3D timeout =3D {tv_sec =3D 0, tv_nsec =3D 39276532} end_time =3D {tv_sec =3D , tv_nsec =3D } timer_delay =3D {tv_sec =3D , tv_nsec =3D } got_output_end_time =3D {tv_sec =3D , tv_nsec =3D } wait =3D got_some_output =3D -1 prev_wait_proc_nbytes_read =3D 0 retry_for_async =3D count =3D {bytes =3D } now =3D {tv_sec =3D , tv_nsec =3D } #35 0x000055e773f28d48 in sit_for (timeout=3Dtimeout@entry=3D0x7a, reading=3Dreading@entry=3Dtrue, displa= y_option=3Ddisplay_option@entry=3D1) at ../../emacs/src/dispnew.c:7007 sec =3D 30 nsec =3D 0 do_display =3D true curbuf_eq_winbuf =3D true nbytes =3D #36 0x000055e774049751 in read_char (commandflag=3D1, map=3Dmap@entry=3D0x7f4fe3bb2743, prev_event=3D0x0, u= sed_mouse_menu=3Dused_mouse_menu@entry=3D0x7ffd6a2b2f8b, end_time=3Dend_tim= e@entry=3D0x0) at ../../emacs/src/keyboard.c:2942 tem0 =3D timeout =3D 30 count1 =3D {bytes =3D } delay_level =3D buffer_size =3D c =3D local_getcjmp =3D {{__jmpbuf =3D {139983216267777, -718546904814463= 4495, 94452706735984, 0, 5961, 139981099837251, -7185469048002028159, -4000= 276575438611071}, __mask_was_saved =3D 0, __saved_mask =3D {__val =3D {128,= 0, 0, 139981142478776, 94452574418320, 140726384668096, 94452572778276, 13= 9982496915949, 139981099825088, 139983273579872, 139983297782696, 140726384= 668064, 94452572696013, 140726384668096, 45530698062208, 140726384668208}}}} save_jump =3D {{__jmpbuf =3D {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_s= aved =3D 0, __saved_mask =3D {__val =3D {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 9445= 2572778135, 0, 0, 3, 94452572190992, 140726384659360}}}} tem =3D save =3D previous_echo_area_message =3D 0x0 also_record =3D 0x0 reread =3D false recorded =3D false polling_stopped_here =3D false orig_kboard =3D 0x55e77c087770 retry =3D jmpcount =3D {bytes =3D } c_volatile =3D 0x0 #37 0x000055e77404ab21 in read_key_sequence (keybuf=3Dkeybuf@entry=3D0x7ffd6a2b30c0, prompt=3Dprompt@entry=3D0x0, d= ont_downcase_last=3Ddont_downcase_last@entry=3Dfalse, can_return_switch_fra= me=3Dcan_return_switch_frame@entry=3Dtrue, fix_current_buffer=3Dfix_current= _buffer@entry=3Dtrue, prevent_redisplay=3Dprevent_redisplay@entry=3Dfalse, = disable_text_conversion_p=3Dfalse) at ../../emacs/src/keyboard.c:10932 interrupted_kboard =3D 0x55e77c087770 interrupted_frame =3D key =3D used_mouse_menu =3D false echo_local_start =3D 0 last_real_key_start =3D keys_local_start =3D 0 new_binding =3D count =3D {bytes =3D } t =3D echo_start =3D 0 keys_start =3D 0 current_binding =3D 0x7f4fe3bb2743 first_unbound =3D 31 mock_input =3D used_mouse_menu_history =3D {false } fkey =3D {parent =3D 0x7f506743f903, map =3D 0x7f506743f903, start = =3D 0, end =3D 0} keytran =3D {parent =3D 0x7f5064402d0b, map =3D 0x7f5064402d0b, sta= rt =3D 0, end =3D 0} indec =3D {parent =3D 0x7f506743f8eb, map =3D 0x7f506743f8eb, start= =3D 0, end =3D 0} shift_translated =3D delayed_switch_frame =3D original_uppercase =3D original_uppercase_position =3D disabled_conversion =3D starting_buffer =3D fake_prefixed_keys =3D 0x0 first_event =3D 0x0 second_event =3D #38 0x000055e77404c8a8 in command_loop_1 () at ../../emacs/src/keyboard.c:1= 441 cmd =3D keybuf =3D {0x1e2, 0x18a, 0x1de, 0x0, 0xffffffffffffffff, 0x55e7742= 57590, 0x7ffd6a2b3160, 0x55e7740c6f24 , 0x7f4fe2d1ca2b, 0x7f= fd6a2b3180, 0xc, 0x13cf8, 0x38, 0x7f4fe15cf0b5, 0x2968f69e5cc8, 0x7f4fe2d1c= a2b, 0x60, 0x7ffd6a2b3180, 0xffffffffffffffff, 0x7ffd6a2b3338, 0x7ffd6a2b31= e0, 0x55e77403facd , 0x0, 0x0, 0xffffffffffffff00, 0x55e7742= 57590, 0x7ffd6a2b3200, 0x55e7740c6f24 , 0x0, 0xcd68} i =3D last_pt =3D prev_modiff =3D 52791 prev_buffer =3D 0x7f4fe645cfb8 #39 0x000055e7740c5c36 in internal_condition_case (bfun=3Dbfun@entry=3D0x55e77404c6f0 , handlers=3Dhandle= rs@entry=3D0xa8, hfun=3Dhfun@entry=3D0x55e77403f970 ) at ../../e= macs/src/eval.c:1713 val =3D c =3D 0x55e77bd0b580 #40 0x000055e77403758e in command_loop_2 (handlers=3Dhandlers@entry=3D0xa8)= at ../../emacs/src/keyboard.c:1180 val =3D #41 0x000055e7740c5b62 in internal_catch (tag=3Dtag@entry=3D0x15118, func=3Dfunc@entry=3D0x55e774037560 , arg=3Darg@entry=3D0xa8) at ../../emacs/src/eval.c:1393 val =3D c =3D #42 0x000055e774037523 in command_loop () at ../../emacs/src/keyboard.c:1158 #43 0x000055e77403f4e6 in recursive_edit_1 () at ../../emacs/src/keyboard.c= :766 count =3D {bytes =3D } val =3D #44 0x000055e77403f898 in Frecursive_edit () at ../../emacs/src/keyboard.c:= 849 count =3D {bytes =3D } buffer =3D #45 0x000055e773f1c415 in main (argc=3D, argv=3D0x7ffd6a2b35= 58) at ../../emacs/src/emacs.c:2651 stack_bottom_variable =3D 0x55e77bbd1b60 old_argc =3D no_loadup =3D false junk =3D 0x0 dname_arg =3D 0x0 ch_to_dir =3D 0x0 original_pwd =3D dump_mode =3D skip_args =3D 1 temacs =3D 0x0 attempt_load_pdump =3D only_version =3D false rlim =3D {rlim_cur =3D 10022912, rlim_max =3D 18446744073709551615} lc_all =3D sockfd =3D -1 module_assertions =3D (gdb)=20 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=3D-O2 -fno-omit-frame-pointer -g3' CPPFLAGS=3D-I/home/oscar/dev/include/mps LDFLAGS=3D-L/home/oscar/dev/other/mps/code --with-native-compilation --with-tree-sitter --without-toolkit-scroll-bars --with-x-toolkit=3Dlucid --with-modules --without-imagemagick --with-mps=3Dyes' 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/l= isp/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)) From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 31 01:11:13 2025 Received: (at 79131) by debbugs.gnu.org; 31 Jul 2025 05:11:13 +0000 Received: from localhost ([127.0.0.1]:45230 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhLZQ-00058y-On for submit@debbugs.gnu.org; Thu, 31 Jul 2025 01:11:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48000) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uhLZN-00058Z-VM for 79131@debbugs.gnu.org; Thu, 31 Jul 2025 01:11:11 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uhLZH-0001xL-Fk; Thu, 31 Jul 2025 01:11:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:References:Subject:In-Reply-To:To:From: Date; bh=eQUnGwYya6sF/fBPQ4q2C546uHoRF1aczTHywqQJs2o=; b=QGV2xzrgMTQK9hdHTeJc L2NntP1CDsiUyQ9sEzTHUl0aKnipv8V6JV0ApidE5st+TvaXIj4JKhKwCTl3i41YAFgnwKcIi/SY0 c/dAJvyk3OKduF5NWpbbIzpFDxG6w2KYjurW65TEftcgOV7v3vYbDR9Ho5v4lqfh0WbgBhoqZzLMS 0XPUlUW2zMhpKoYxvKnoZMnRs5rarmhcvY1ZElKm/iAR3IqCOTAXN6WvaZh5pNnp6xaujl2SJq8Mr TD+ixP8exmST63zA/+WYR1x7+onxSUIPabfFhJEVsrA5mrfyBdhMIi/9vsFAyZ6kdt1f9lZKqEUSk fB3pwLHcYtnw/g==; Date: Thu, 31 Jul 2025 08:11:00 +0300 Message-Id: <86ikj9ueqj.fsf@gnu.org> From: Eli Zaretskii To: =?iso-8859-1?Q?=D3scar?= Fuentes , Yuan Fu In-Reply-To: <878qk5qvob.fsf@telefonica.net> (bug-gnu-emacs@gnu.org) Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV References: <878qk5qvob.fsf@telefonica.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79131 Cc: gerd.moellmann@gmail.com, 79131@debbugs.gnu.org, pipcet@protonmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: Pip Cet , > Gerd M=F6llmann > Date: Wed, 30 Jul 2025 22:18:44 +0200 > From: =D3scar Fuentes via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" >=20 >=20 > 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. >=20 > Backtrace from the coredump: >=20 > (gdb) bt full > #0 __pthread_kill_implementation (threadid=3D, signo=3Dsi= gno@entry=3D11, no_tid=3Dno_tid@entry=3D0) > at ./nptl/pthread_kill.c:44 > tid =3D > ret =3D 0 > pd =3D > old_mask =3D {__val =3D {94452575465120}} > ret =3D > #1 0x00007f506ce9e9ff in __pthread_kill_internal (threadid=3D, signo=3D11) > at ./nptl/pthread_kill.c:89 > #2 0x00007f506ce49cc2 in __GI_raise (sig=3Dsig@entry=3D11) at ../sysdeps= /posix/raise.c:26 > ret =3D > #3 0x000055e773f12db8 in terminate_due_to_signal > (sig=3Dsig@entry=3D11, backtrace_limit=3Dbacktrace_limit@entry=3D40) = at ../../emacs/src/emacs.c:481 > #4 0x000055e773f132de in handle_fatal_signal (sig=3Dsig@entry=3D11) at .= ./../emacs/src/sysdep.c:1793 > #5 0x000055e773f132e5 in deliver_thread_signal > (sig=3Dsig@entry=3D11, handler=3D0x55e773f132d0 = ) at ../../emacs/src/sysdep.c:1785 > old_errno =3D > #6 0x000055e774058dec in deliver_fatal_thread_signal (sig=3D11) at ../..= /emacs/src/sysdep.c:1805 > #7 handle_sigsegv (sig=3D11, siginfo=3D, arg=3D) at ../../emacs/src/sysdep.c:1943 > fatal =3D > #8 0x00007f506ce49df0 in () at /lib/x86_64-linux= -gnu/libc.so.6 > #9 0x00007f506ce4a007 in __GI_kill () at ../sysdeps/unix/syscall-templat= e.S:120 > #10 0x000055e774215e44 in sigHandle () > #11 0x00007f506ce49df0 in () at /lib/x86_64-linux= -gnu/libc.so.6 > #12 add_text_properties_1 (start=3D, start@entry=3D0x1f06a= , end=3D,=20 > end@entry=3D0x1f07a, properties=3D0x7f4fe3c2acc3, object=3D0x7f4fe645= cfbd,=20 > object@entry=3D0x0, set_type=3Dset_type@entry=3DTEXT_PROPERTY_REPLACE= , destructive=3Ddestructive@entry=3Dtrue) > --Type for more, q to quit, c to continue without paging--c > at ../../emacs/src/textprop.c:1252 > i =3D 0x0 > unchanged =3D > s =3D 31770 > len =3D 3 > modified =3D > first_time =3D 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 !=3D 0); if (LENGTH (i) >=3D 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=3D0x1f06a, end=3D0x1f07a, properties=3D, object= =3D0x0) at ../../emacs/src/textprop.c:1308 > #14 Fput_text_property > (start=3D0x1f06a, end=3D0x1f07a, property=3D, value=3D= , object=3D0x0) > at ../../emacs/src/textprop.c:1326 > properties =3D > #15 0x00007f505801aec2 in F747265657369742d2d666f6e742d6c6f636b2d6d61726b= 2d72616e6765732d746f2d666f6e74696679_treesit__font_lock_mark_ranges_to_font= ify_0 () > at /home/oscar/.emacs.d/eln-cache/31.0.50-3eae311e/treesit-37439c61-2= c208e3a.eln > #16 0x000055e7740c8e8c in Ffuncall (nargs=3D2, args=3D0x7ffd6a2b0e70) at = ../../emacs/src/eval.c:3201 > count =3D {bytes =3D } > val =3D > #17 0x00007f505801b396 in F747265657369742d2d7072652d7265646973706c6179_t= reesit__pre_redisplay_0 () > at /home/oscar/.emacs.d/eln-cache/31.0.50-3eae311e/treesit-37439c61-2= c208e3a.eln > #18 0x000055e7740c8e8c in Ffuncall (nargs=3D2, args=3D0x7ffd6a2b0f80) at = ../../emacs/src/eval.c:3201 > count =3D {bytes =3D } > val =3D > #19 0x000055e7740c90e9 in funcall_nil (nargs=3D, args=3D) > at ../../emacs/src/eval.c:2884 > #20 0x000055e7740c643d in run_hook_with_args > (nargs=3D2, args=3D0x7ffd6a2b0f80, funcall=3D0x55e7740c90e0 ) at ../../emacs/src/eval.c:3061 > global_vals =3D > sym =3D 0x2968c2d2eba0 > val =3D 0x7f4fe52f5c83 > ret =3D 0x0 > #21 0x000055e7740c8e8c in Ffuncall (nargs=3D3, args=3D0x7ffd6a2b0f78) at = ../../emacs/src/eval.c:3201 > count =3D {bytes =3D } > val =3D > #22 0x00007f505b7c1d34 in F7265646973706c61792d2d7072652d7265646973706c61= 792d66756e6374696f6e73_redisplay__pre_redisplay_functions_0 () > at /home/oscar/dev/emacs/igc/build/src/../native-lisp/31.0.50-3eae311= e/preloaded/simple-fab5b0cf-fea6411a.eln > #23 0x000055e7740c8e8c in Ffuncall (nargs=3Dnargs@entry=3D2, args=3Dargs@= entry=3D0x7f505ad28040) > at ../../emacs/src/eval.c:3201 > count =3D {bytes =3D } > val =3D > #24 0x000055e7740c7742 in Fapply (nargs=3D2, args=3D0x7f505ad28040) at ..= /../emacs/src/eval.c:2830 > i =3D > funcall_nargs =3D > funcall_args =3D 0x0 > spread_arg =3D > fun =3D 0x2968f6dc91d8 > sa_avail =3D 16384 > sa_count =3D {bytes =3D } > numargs =3D > retval =3D > #25 0x000055e77411753a in exec_byte_code > (fun=3D, args_template=3D, nargs=3D, args=3D) > at ../../emacs/src/lisp.h:2306 > call_nargs =3D 2 > call_fun =3D > count1 =3D {bytes =3D } > val =3D > call_args =3D 0x7f505ad28040 > original_fun =3D 0x43d0 > op =3D 2 > type =3D > targets =3D {0x55e773f17ee1 , 0x55e774117= 93f , 0x55e77411793a , 0x55e77411= 7935 , 0x55e77411731d , 0x55e77411= 731d , 0x55e7741178f7 , 0x55e77411= 78b9 , 0x55e7741198e2 , 0x55e774= 1198dd , 0x55e7741198d8 , 0x55e= 7741198d3 , 0x55e774117357 , 0x55= e774117360 , 0x55e7741198c6 , 0x5= 5e7741198e7 , 0x55e77411976e , 0= x55e774119769 , 0x55e774119764 , = 0x55e77411975f , 0x55e7741172b9 , = 0x55e7741172c0 , 0x55e774119745 , = 0x55e774119752 , 0x55e7741196f3 ,= 0x55e7741196ee , 0x55e7741196e9 = , 0x55e7741196e4 , 0x55e7741175ef , 0x55e7741175f0 , 0x55e774119705 , 0x55e7741196f8 , 0x55e7741196c5 , 0x55e7741196c0 , 0x55e7741196bb , 0x55e7741196b6 , 0x55e7741173bd , 0x55e7741173c0 , 0x55e7741196d7 , 0x55e7741196ca , 0x55e774119697 , 0x55e774119692 , 0x55e77411968d , 0x55e774119688 , 0x55e774117639 , 0x55e774117640 , 0x55e7741196a9 , 0x55e77411969c , 0x55e774119273 , 0x55e7741192a7 , 0x55e774119330 , 0x55e773f17ee1 , 0x55e773f17ee1 , 0x55e773f17ee1 , 0x55e773f17ee1 = , 0x55e773f17ee1 , 0x55e774= 1190c7 , 0x55e774119054 , 0x55e77= 411900d , 0x55e774118fc6 , 0x55e7= 74118f81 , 0x55e7741197ef , 0x55e= 7741197af , 0x55e774118f4f , 0x55= e77411984b , 0x55e774119773 , 0x5= 5e774118f0f , 0x55e774118edf , 0x= 55e774118e9f , 0x55e774118e62 , 0= x55e774118e21 , 0x55e774118dab , = 0x55e774118d20 , 0x55e774118c8b ,= 0x55e774118c5b , 0x55e774118c2b = , 0x55e774118beb , 0x55e774118bab , 0x55e774118b6b , 0x55e774118b27 , 0x55e774118aed , 0x55e774118ab3 , 0x55e774118a79 , 0x55e7741189d7 , 0x55e77411897b , 0x55e774118921 , 0x55e7741188c7 , 0x55e77411886d , 0x55e774118813 , 0x55e7741187b9 , 0x55e774118761 , 0x55e774118704 , 0x55e7741186ac , 0x55e774118654 , 0x55e7741185fc , 0x55e7741185a3 , 0x55e7741184b2 , 0x55e774117689 , 0x55e774118482 , 0x55e77411844d , 0x55e7741183bd , 0x55e774118373 , 0x55e774118343 , 0x55e774118311 , 0x55e7741182df , 0x55e7741182a5 , 0x55e774118273 , 0x55e773f17ee1 , 0x55e774118241 , 0x55e77411820f <= exec_byte_code+4303>, 0x55e7741181dd , 0x55e7741181ab = , 0x55e774118179 , 0x55e774118149= , 0x55e774117689 , 0x55e773f17ee= 1 , 0x55e774118105 , 0x55e7741= 180d4 , 0x55e7741180a3 , 0x55e774= 118062 , 0x55e774118021 , 0x55e77= 4117ff0 , 0x55e774117fbf , 0x55e7= 74117f7e , 0x55e774117f3d , 0x55e= 774117efc , 0x55e774117ec9 , 0x55= e774117e98 , 0x55e773f17ee1 , = 0x55e77411943f , 0x55e774119615 ,= 0x55e774119887 , 0x55e7741195d6 , 0x55e77411959a , 0x55e77411955e , 0x55e77411949d , 0x55e774119478 , 0x55e774119712 , 0x55e77411941a , 0x55e7741193b7 , 0x55e774119382 , 0x55e77411933b , 0x55e77411921e , 0x55e7741191da , 0x55e774119190 , 0x55e774119125 , 0x55e773f17ee1 , 0x55e774117e53 , 0x55e774117e22 , 0x55e774117df1 , 0x55e774117dc0 , 0x55e774117d8f , 0x55e774117d4e , 0x55e774117d0d , 0x55e774117ccc , 0x55e774117c8b , 0x55e774117c24 , 0x55e774117be3 , 0x55e774117ba2 , 0x55e774117b71 , 0x55e774117b25 , 0x55e774117ad9 , 0x55e774117a9b , 0x55e774117a5d , 0x55e774117a22 <= exec_byte_code+2274>, 0x55e77411854b , 0x55e7741184fc = , 0x55e7741179b2 , 0x55e774117944= , 0x55e773f17ee1 , 0x55e773f1= 7ee1 , 0x55e773f17ee1 , 0x5= 5e773f17ee1 , 0x55e773f17ee1 , 0x55e773f17ee1 , 0x55e774118ddb , 0x55e774118a33 , 0x55e774118407 , 0x55e774117873 , 0x55e77411782d , 0x55e773f17ee1 , 0x55e773f17ee1 , 0x55e7741177f4 , 0x55e774117790 , 0x55e773f17ee1 , 0x55e773f17ee1 <= exec_byte_code-2093663>, 0x55e773f17ee1 , 0x55e773f= 17ee1 , 0x55e773f17ee1 , 0x= 55e773f17ee1 , 0x55e773f17ee1 , 0x55e773f17ee1 , 0x55e774117756 } > quitcounter =3D > bc =3D 0x55e7742cb858 > top =3D 0x7f505ad28038 > pc =3D > bytestr =3D > vector =3D > maxdepth =3D > const_length =3D > bytestr_length =3D > vectorp =3D 0x7f506b0a53f0 > max_stack =3D > frame_base =3D > fp =3D > bytestr_data =3D > rest =3D > mandatory =3D > nonrest =3D > pushedargs =3D > saved_quitcounter =3D 0 '\000' > saved_vectorp =3D 0xdd98 > saved_bytestr_data =3D 0x7ffd00000002 > result =3D > #26 0x000055e7740c8e8c in Ffuncall (nargs=3Dnargs@entry=3D2, args=3Dargs@= entry=3D0x7ffd6a2b1290) > at ../../emacs/src/eval.c:3201 > count =3D {bytes =3D } > val =3D > #27 0x000055e7740c5dbe in internal_condition_case_n > (bfun=3Dbfun@entry=3D0x55e7740c8d90 , nargs=3Dnargs@entry= =3D2, args=3Dargs@entry=3D0x7ffd6a2b1290, handlers=3Dhandlers@entry=3D0x38,= hfun=3Dhfun@entry=3D0x55e773f4e550 ) at ../../emacs/sr= c/eval.c:1793 > val =3D > c =3D 0x55e77bd0b710 > #28 0x000055e773f3bc04 in dsafe__call > (inhibit_quit=3Dinhibit_quit@entry=3Dtrue, f=3D0x55e7740c8d90 , nargs=3Dnargs@entry=3D2, args=3Dargs@entry=3D0x7ffd6a2b1290) at ../../= emacs/src/xdisp.c:3106 > count =3D {bytes =3D } > redisplay_counter_before =3D 939536 > val =3D > #29 0x000055e773f6efbe in dsafe__call (inhibit_quit=3Dtrue, nargs=3D2, f= =3D, args=3D0x7ffd6a2b1290) > at ../../emacs/src/xdisp.c:3094 > val =3D > count =3D {bytes =3D } > redisplay_counter_before =3D > #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. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 31 01:42:21 2025 Received: (at 79131) by debbugs.gnu.org; 31 Jul 2025 05:42:21 +0000 Received: from localhost ([127.0.0.1]:45446 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhM3Z-0007ab-Cg for submit@debbugs.gnu.org; Thu, 31 Jul 2025 01:42:21 -0400 Received: from mail-ej1-x630.google.com ([2a00:1450:4864:20::630]:50358) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uhM3X-0007a9-5c for 79131@debbugs.gnu.org; Thu, 31 Jul 2025 01:42:19 -0400 Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-af8f5e38a9fso781666b.0 for <79131@debbugs.gnu.org>; Wed, 30 Jul 2025 22:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753940533; x=1754545333; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=8i5zLEGzBHl42R9naEOyuOCdm94r0ozTTTPacIEuffk=; b=L5EirvJCNTfHWvujW7hX//0ZFfCQzJXp/8o8XJ4e4U9G4U4j79wzgfA33M0VfolDQd ULtnkGqmqtLjTGSbPT8vHSRDlmLqkHieALKbDSGx94h3+USyWG8IXxYzqs2LqnQIpOW/ 8khQRn4TnmctJLN9pEeunJ5Ois3FZFX1CM6V9w7y+EhUn+p1iFpP30XRa0e8EyS9srNO zl7FnYB/85ZhfkjbLwTZTx+v2H8KMVD1mmxdFALC343nUCcfxhH6LMiwixXm7Qw3a0IF rXXWhRfQK5eyOpsedG72h+3DXQFPgSPblTT8OCb3T3naRPHaB3xq5kjI4OXpA3hRrjh5 zIHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753940533; x=1754545333; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=8i5zLEGzBHl42R9naEOyuOCdm94r0ozTTTPacIEuffk=; b=UWaEHOcqw1Ee8Q2CgUOPkKjmplmDXEOg/BCdLgLVvGIxJe5E/e+OhpCvg8gsryzJiD qLak3ji4YBptsYD1YJ8bw0j5MrqJ+nVE3hIY8U/Rz9LV7QJEOM9GDvJdilHHE7YjSihl hge15O0xUGQTNrn7F74Y4jepvNkeu5MZ0o12n32hBBLJNeSq2x6nHULmZCwtNDdqZUUh jmhENTM1H93JVzZgW1qh2NJESQN3/A3pXtyRSmli/qLW17+Pobs/N0XyaunvrkMSnzR0 p1gXQmwvBibjZmjndWD0kqjeidl2PsnLD1VUCooRP8ccLoNpdvvHQQl6S4W/ZiCRmhvK kHPQ== X-Gm-Message-State: AOJu0YzJWDvhwoyDBwctoiETwSDG0beAqoLkHt/lTq3qv6OkoNIBN4hL 5gBZ0rHDun8VZRQAuN8W2UdOt9Kn64Dn+GQbqfZkiVFYQXqyEqfRyiYp X-Gm-Gg: ASbGncsgHcQNG57pQI8yo8sHs7+PJU29CfbyL5c7mjWIoGR+rqrdIUYtyGd4/GIOwRg BXUj7G68tIvyLabaQe0WHU1hLj2XqvY+7TT8rU1adcWENMzHURQNqXyAL8vmjxCRgcf8RTD44jR YRstgF2KhUD1t/wblaN0z6In4TaEJ5zCDqc5CJOU8674fjIY3t2h/fmov2bcDTuMlwKCLqrUFfn kbEuQalY+5Vohi4IPfvN9ayJjtqL/sdv8YburB76cRrvVTpW/1ncKxUSVwMTT+GmCUAEBwmImDO T9VwQmX3P0YbFfEvAARH9g7/O53j35S3TGkraelEkKKHZ9UwF5rWPvsly8hagE1AKvjOKLRPsdt bti4t2543TCo0qbHhoUFRTzFJ9IJFCLyADMtGbrjq/z5a9GPNZ4FGv4Gtnr544dEEBvp5Wdr6oP +ssUjvPx5JQUM4T899gB2MclY3yA== X-Google-Smtp-Source: AGHT+IEINqc80UJhutYEy4aHMvhKkbww2GerNdPTPwzS8kqi0il/Dg5T+lBGpdjNZpU8P3OYJQhZvA== X-Received: by 2002:a17:906:9fc7:b0:ae0:c8b2:3fc0 with SMTP id a640c23a62f3a-af8fd680ce8mr676989166b.10.1753940532363; Wed, 30 Jul 2025 22:42:12 -0700 (PDT) Received: from pro2 (p200300e0b70f1400d179419dbe2241c4.dip0.t-ipconnect.de. [2003:e0:b70f:1400:d179:419d:be22:41c4]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-af91a21c022sm50588266b.101.2025.07.30.22.42.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Jul 2025 22:42:11 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: =?utf-8?Q?=C3=93scar?= Fuentes Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV In-Reply-To: <878qk5qvob.fsf@telefonica.net> References: <878qk5qvob.fsf@telefonica.net> Date: Thu, 31 Jul 2025 07:42:11 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79131 Cc: 79131@debbugs.gnu.org, Pip Cet X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) =C3=93scar Fuentes writes: > #12 add_text_properties_1 (start=3D, start@entry=3D0x1f06a= , end=3D,=20 > end@entry=3D0x1f07a, properties=3D0x7f4fe3c2acc3, object=3D0x7f4fe645= cfbd,=20 > object@entry=3D0x0, set_type=3Dset_type@entry=3DTEXT_PROPERTY_REPLACE= , destructive=3Ddestructive@entry=3Dtrue) > --Type for more, q to quit, c to continue without paging--c > at ../../emacs/src/textprop.c:1252 > i =3D 0x0 > unchanged =3D > s =3D 31770 > len =3D 3 > modified =3D > first_time =3D 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 !=3D 0); 1255=20 1256 if (LENGTH (i) >=3D 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? From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 31 03:19:25 2025 Received: (at submit) by debbugs.gnu.org; 31 Jul 2025 07:19:25 +0000 Received: from localhost ([127.0.0.1]:46116 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhNZU-0006Tg-Vw for submit@debbugs.gnu.org; Thu, 31 Jul 2025 03:19:25 -0400 Received: from lists.gnu.org ([2001:470:142::17]:36094) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uhNZS-0006TB-IX for submit@debbugs.gnu.org; Thu, 31 Jul 2025 03:19:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uhNZL-0000yP-8y for bug-gnu-emacs@gnu.org; Thu, 31 Jul 2025 03:19:16 -0400 Received: from mail-0301.mail-europe.com ([188.165.51.139]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uhNZI-00004t-LQ for bug-gnu-emacs@gnu.org; Thu, 31 Jul 2025 03:19:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1753946345; x=1754205545; bh=mkaFaqsXljtOVH41/4uAFNezp0OLC0iKzarVY+0jI6Q=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=mp9U+8/5E0fweqH0RaBW9xjNW5TGiGaTL9UASg1k+vy69VoYYoqvNd9vjzI5UwN4r CO2M/pXFFdEwh6SCToS0b+a/kcExRBo6StoOo1NVf/uiBigLw8j45Dgi82eOp5qikY ldFviqCzgTRVWxCQrABCvkL9LCEUYZ4r/+v5QqtRPAa0MXj61iDQnQAEbx7Fa7zdLu +euzHXf5oVk9Q7n4WjN5Sx8oOovwuU9qb20EkhBdGdIALvbJ+webM7FFdRxqNX2Io4 eFAFKjqMHN/l98bZslSYp/Yz+J0GSQR/VC60hA898Be7I6msJ8V3kJ3Ps0UFDbIXPI n0U+dYx1MZ01w== Date: Thu, 31 Jul 2025 07:19:01 +0000 To: =?utf-8?Q?=C3=93scar_Fuentes_via_Bug_reports_for_GNU_Emacs=2C_the_Swiss_army_knife_of_text_editors?= From: Pip Cet Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Message-ID: <87tt2sbzgf.fsf@protonmail.com> In-Reply-To: <878qk5qvob.fsf@telefonica.net> References: <878qk5qvob.fsf@telefonica.net> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 5e57f899a6b4b02a87180ee4944bcef3ac1c66d9 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=188.165.51.139; envelope-from=pipcet@protonmail.com; helo=mail-0301.mail-europe.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= , =?utf-8?Q?=C3=93scar_Fuentes?= , 79131@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) =C3=93scar Fuentes via "Bug reports for GNU Emacs, the Swiss army knife of = text editors" 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 =3D current_buffer->text->intervals and then repeat p *$i p $i =3D $i->right until $i is NULL. Also, can you print igc__balance_intervals to verify it's false? Thanks! Pip From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 31 03:21:52 2025 Received: (at submit) by debbugs.gnu.org; 31 Jul 2025 07:21:52 +0000 Received: from localhost ([127.0.0.1]:46129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhNbs-0006ho-Dw for submit@debbugs.gnu.org; Thu, 31 Jul 2025 03:21:52 -0400 Received: from lists.gnu.org ([2001:470:142::17]:46300) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uhNbp-0006h1-9B for submit@debbugs.gnu.org; Thu, 31 Jul 2025 03:21:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uhNbf-00044b-BF for bug-gnu-emacs@gnu.org; Thu, 31 Jul 2025 03:21:42 -0400 Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1uhNbd-0000mD-Pi for bug-gnu-emacs@gnu.org; Thu, 31 Jul 2025 03:21:39 -0400 Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-3b79bddd604so51750f8f.0 for ; Thu, 31 Jul 2025 00:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753946496; x=1754551296; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=FGknxZonljEkZXPi70rQVNbsoKj7GoMDO5M2g/IMQ3A=; b=ArTQfZKD8ySTuDYqTgxUH8QbZQgPb0jFHs1OMJRQXGkYTZzDYcex3yijIVngW9Fyt3 +ronf+yzEzerx/OI0uOzTsLiMzX6TjU9Sb8epNtiD+yJ4GYTgpGhZXcybUsyvoAX44j4 jLG1wbpJXQaHbkbFsP9nr0bErUuOnyRxuytS77NPUS8NkfS5twIfaYHgr2xag/lKKTF6 BXBx9dhVymRIwBhgTWfOBmoqpYEQR+IJznLk03r2i/DLwyUbajJCRMTTefMcYELoIX5v TzYa41AfovxGnbyESCSeIQ1lplB9QDVdRulnz9HQJeqYj5rSDQ135IuE0Qzs9UrJkZH+ +UHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753946496; x=1754551296; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=FGknxZonljEkZXPi70rQVNbsoKj7GoMDO5M2g/IMQ3A=; b=gHpO0TE+bONLAjA4qfZiF/D2zhQFMfzmXugjVin4qnnadQoRFoNutcYkwQU9/s+wxT 8xqQbZre6Em5ZxSyoV+1la/JXoIm7/eeEgdA20X636PQYh9PAQ/LtGAO1mb/Y7rL4+W3 p1HtG46lNmmtf42IxBD6WaBDMBctUDgUk/W2J38DEZ/dv25QiP12ukWembIKn0rVDxDX bmAXjGLG+hZ4XXb81hUrCQHa6gbrHALSlXKNlywv5bAjHfwjyjcl8980whFKrAY86GnB O3EYzVtYr934CTf7wzh2Wr+pmDBCeVyeBKYU10ekfeCFQmrMEKlHQDpaIKru6q/DgsB/ rxOw== X-Gm-Message-State: AOJu0YyzZzNZHe4cmliReX2Yy/2PiiyG6jIaYqxRnm2xKYsX220D9dzI 5hq7xugsXX2IVGTuMmf++Z5NZo+KUmORXL000UF18L3HErMtrsmnbKv9 X-Gm-Gg: ASbGncsq+uQOFL6ESOQG40FMpILxhGOBRBhxiN620Y568SIphNM81K0+J5Pgdkfz0Z5 9P43Xqig87gSeD2fbjmRuxqWrfxgTKIwooIcJoC0VRPpHnh1hSiNgT+niLFyhwSDAhtLr23h590 aYKQUeGTMAzRdVwKDzQFONFn81AQrYZNgTFhU9VIn+5Grmym7olNB+rsxuW0ZCaX9azuueq6gFZ cdUVARQkvuKZMW4JZdIEQWzaYzLS0kCUl+99CI2f55maad/KSjQH7C31FDGpmvaWEuQIYFnSnMg XgRWWFxIubCsaWo94bZ7X+pJRlfiCGN/QsDSseIMu0X/76wcKuLEi5HmtqXv8BrerBCshQxPe28 L8pU/ObCCmVkNFSwkZgaT1fH3e718vl24Unnw+VN7c15KltkPBqKUydlnv0arclmqdwHdx0WaFs zElvY6AFzV65SpWUxa4TK7cfNjSnlE5fE= X-Google-Smtp-Source: AGHT+IHnRumyvp58W8vFNE45QnOyQko/jYqcteobt9kTcRqmI7J0sDAvh4Q4d9nvVht8it/nuetCzg== X-Received: by 2002:a05:6000:4287:b0:3b6:db7:5c0d with SMTP id ffacd0b85a97d-3b794fbe247mr5246138f8f.3.1753946495696; Thu, 31 Jul 2025 00:21:35 -0700 (PDT) Received: from pro2 (p200300e0b70f1400d179419dbe2241c4.dip0.t-ipconnect.de. [2003:e0:b70f:1400:d179:419d:be22:41c4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3b79c3b9eddsm1395783f8f.22.2025.07.31.00.21.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Jul 2025 00:21:35 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Pip Cet Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV In-Reply-To: <87tt2sbzgf.fsf@protonmail.com> References: <878qk5qvob.fsf@telefonica.net> <87tt2sbzgf.fsf@protonmail.com> Date: Thu, 31 Jul 2025 09:21:34 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::42e; envelope-from=gerd.moellmann@gmail.com; helo=mail-wr1-x42e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: =?utf-8?Q?=C3=93scar?= Fuentes , =?utf-8?Q?=C3=93scar_Fuentes_via_Bug_reports_for_GNU_Emacs=2C_the_Swis?= =?utf-8?Q?s_army_knife_of_text_editors?= , 79131@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) I'm in the process of merging master, BTW. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 31 03:46:44 2025 Received: (at submit) by debbugs.gnu.org; 31 Jul 2025 07:46:44 +0000 Received: from localhost ([127.0.0.1]:46245 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhNzw-0008U1-EF for submit@debbugs.gnu.org; Thu, 31 Jul 2025 03:46:44 -0400 Received: from lists.gnu.org ([2001:470:142::17]:59778) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uhNzu-0008T9-8t for submit@debbugs.gnu.org; Thu, 31 Jul 2025 03:46:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uhNzh-0005fu-IJ for bug-gnu-emacs@gnu.org; Thu, 31 Jul 2025 03:46:29 -0400 Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1uhNzf-0006u7-Ox for bug-gnu-emacs@gnu.org; Thu, 31 Jul 2025 03:46:29 -0400 Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-61576e33ce9so1049348a12.1 for ; Thu, 31 Jul 2025 00:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753947985; x=1754552785; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=UmbMQ3C5org/4jVWs89fLDoDH4SoGUqCxsfR05AWDks=; b=YjAiwAMLYpcA1mSamOQvXdsMvpROhKdW2hGLs3VHQOaEbcvkYJCeyLDA6LBHNxLwHu kfJVnLx1ETQwkOjmzTj0DFvOfF6bFQuf7LP75Bq0p7mCWKeNdm3DhNtG1lFkoIztvNta clWxsBrGp7u2oGKLnhenBk619CLHPGLsb4XqDNdAnM7y2hIJJauRgxioO5EUCA4KcN7n GhZka1jzJBs0bWi0gOKSL2u+hmXXgxlXSv3/RQ/zwjMSYr+xg+1GZg/SX2xfZGZzgWc0 mt0hiyQdCt2zw6ceJVzuP6/6xNLck7oI5DlbgISqOFMGLsH60xh/HmIG68YRYbb0RKNF /Exw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753947985; x=1754552785; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=UmbMQ3C5org/4jVWs89fLDoDH4SoGUqCxsfR05AWDks=; b=v6FdHHAPeKigRpE6mX7a20WtFOxBBq7tG4aA+21pQ5vKTWnoPtYKBZsdxQWaQIsIPW oejd3jf1MumP0f+luSbJ6rd5vF73rf+s3B2+JdOWFAEag/jxOxaO3kvVp2oGPu2L3MbL PG3VG59y+huDj+45GEigBLiq1Ux8/dO+o7SLoPeKYs1n6fTOZUnGVs0NbUGGCNFKVII5 tlt18ylhG0QtyvaUTcYpyQHa0QIPjWlTm996APsIf9ywBlsqUWcWTM0xuYhEXt8RJoxF 8jlPPbF5XqVxKRXsLxJfx2TW3Nmk3d9oA9QVfgYy6QUUh3tkSwgLCJzkb7IQKmJXBfJd ds9g== X-Gm-Message-State: AOJu0Yw6rzvQipHpjJZWNPxFaqui6U0MGvN9qb5Dpwd9XNzMoMhwtbQ5 kYShUsV39n6PQjC3kkuY1MGXRGVlAiYXvrrD0QEu9yiWV3F40j8GugU/PZCLPzBG X-Gm-Gg: ASbGncvurkcI7/MTdGBE/z+010JM0/9hsw+ozoRKccDZXf/oWXs0d8MjvuxaCWweT1M ggCq8TQ5DgT30Ba8LCdIASB4to/gWnNcj/uDw2TbcgqAwI5DtE7U5smwZGLEW3t1krQPtBbB4e0 IfphkxdLLGlWRZHsMjSugBD4aoTusRArOTAPy+r/bDafxCJ4A03rBvKLT3dSTNgekE0aKu9/WvK i+DIq1gH5dadAWz3RCZv5FNAXirQwVaX0WQYBsRyr7gRBW5/AYmD53ed2Pi1EVWo+lRoMXAxLXP 9GVWOpk4s5mj55sfXz0SPlLVf7zoFzWWYsfrIu26VjjNHKZ+9CW1mbfd0FIuQ010vjOvQXh0UCp Xgs7FMXVofdklyLqPEsfK/Hv/YGzf5E3QAaJkbau9Si2S5DbpaowapYYhK+hSw8WzUfVf74HHxw tnXymBRV/Cu/z+6e4IBx01rIelkLpDiT4= X-Google-Smtp-Source: AGHT+IGD0d+HHwKDfZB9z0gj+NtZEzV6wIEKNj83IFjANBwrBxA8yk1wIQxPNeg3zxNGzGAe5Gx0Jg== X-Received: by 2002:a17:907:60d2:b0:ae3:a4a6:a32e with SMTP id a640c23a62f3a-af91bf8e015mr127076766b.29.1753947984897; Thu, 31 Jul 2025 00:46:24 -0700 (PDT) Received: from pro2 (p200300e0b70f1400d179419dbe2241c4.dip0.t-ipconnect.de. [2003:e0:b70f:1400:d179:419d:be22:41c4]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-af91a240645sm66994166b.125.2025.07.31.00.46.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Jul 2025 00:46:24 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Pip Cet Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV In-Reply-To: References: <878qk5qvob.fsf@telefonica.net> <87tt2sbzgf.fsf@protonmail.com> Date: Thu, 31 Jul 2025 09:46:23 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::531; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x531.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: =?utf-8?Q?=C3=93scar?= Fuentes , =?utf-8?Q?=C3=93scar_Fuentes_via_Bug_reports_for_GNU_Emacs=2C_the_Swis?= =?utf-8?Q?s_army_knife_of_text_editors?= , 79131@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Gerd M=C3=B6llmann writes: > I'm in the process of merging master, BTW. Done. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 31 05:26:33 2025 Received: (at 79131) by debbugs.gnu.org; 31 Jul 2025 09:26:33 +0000 Received: from localhost ([127.0.0.1]:46736 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhPYW-0006nk-EL for submit@debbugs.gnu.org; Thu, 31 Jul 2025 05:26:33 -0400 Received: from mail.eclipso.de ([217.69.254.104]:50554) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uhPYM-0006mm-Jd for 79131@debbugs.gnu.org; Thu, 31 Jul 2025 05:26:24 -0400 X-ESMTP-Authenticated-User: 000D6BEA From: =?utf-8?Q?=C3=93scar_Fuentes?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclipso.de; s=mail; t=1753953975; bh=0ce+d6atKpKu777+UPwoEorq+amXafWOYhUt0Uq459s=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=JEUOiGi+r3U+tT77XFvXu7yPqF7SPXH2upjQ5vOdTep+v0lxJEnYDAJnl9u/jN4iw 1ui8MbNusamgt3QwrNWJ68T1aLDMLZf1nGEIMUPO71Y+nCx18wyWxnEAdTbUWbUACP Gfzj5CMjac9E4PDC5ztTnsfvHAIFq8ZLE3hHqEOu7NRoN5jVowRnP57LJu2a6/4Dw8 8Zgi/UHhti0cwqAQmBcIiKgYqvZHChEQW1La/b/KLmHfNbLLO19t9bvAbs3WFoXcbC 7ehSttmhXq9kglaB+smRbuc45w9Xy6Y5/vKjhhknd4JRW3DlhYham7YKt8F7efgzFj QPL/l9b5tqVZg== To: Eli Zaretskii Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV In-Reply-To: <86ikj9ueqj.fsf@gnu.org> References: <878qk5qvob.fsf@telefonica.net> <86ikj9ueqj.fsf@gnu.org> Date: Thu, 31 Jul 2025 11:26:14 +0200 Message-ID: <87tt2spv7t.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79131 Cc: gerd.moellmann@gmail.com, pipcet@protonmail.com, Yuan Fu , 79131@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli, Gerd, Pip: Eli Zaretskii writes: >> #12 add_text_properties_1 (start=3D, start@entry=3D0x1f06= a, end=3D,=20 >> end@entry=3D0x1f07a, properties=3D0x7f4fe3c2acc3, object=3D0x7f4fe64= 5cfbd,=20 >> object@entry=3D0x0, set_type=3Dset_type@entry=3DTEXT_PROPERTY_REPLAC= E, destructive=3Ddestructive@entry=3Dtrue) >> --Type for more, q to quit, c to continue without paging--c >> at ../../emacs/src/textprop.c:1252 >> i =3D 0x0 >> unchanged =3D >> s =3D 31770 >> len =3D 3 >> modified =3D >> first_time =3D > > 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 !=3D 0); > > if (LENGTH (i) >=3D 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 =E2=80=98simple.el=E2=80= =99. 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=C3=B6llmann 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 !=3D 0); > 1255=20 > 1256 if (LENGTH (i) >=3D 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=C3=B6llmann writes: > Gerd M=C3=B6llmann writes: > >> I'm in the process of merging master, BTW. > > Done. Thanks! Pip Cet 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=3Dmake_fixnum(31770),= end=3Dmake_fixnum(31774),=20 properties=3D, object=3DXIL(0)) at ../../emacs/src/textp= rop.c:1308 1308 return add_text_properties_1 (start, end, properties, object, (gdb) p *current_buffer->text $1 =3D { beg =3D 0x55e77e157f80 "", gpt =3D 1, z =3D 31775, gpt_byte =3D 1, z_byte =3D 31793, gap_size =3D 1153, modiff =3D 53239, chars_modiff =3D 53237, save_modiff =3D 51987, overlay_modiff =3D 55141, compact =3D 53237, beg_unchanged =3D 0, end_unchanged =3D 1, unchanged_modified =3D 53011, overlay_unchanged_modified =3D 55141, intervals =3D 0x7f4fe5280a28, markers =3D XIL(0x7f4fdc5dc005), inhibit_shrinking =3D false, redisplay =3D true } > Also, can you print igc__balance_intervals to verify it's false? (gdb) p igc__balance_intervals $4 =3D false > in the coredump, then > > p $i =3D current_buffer->text->intervals (gdb) p $i =3D current_buffer->text->intervals $2 =3D (INTERVAL) 0x7f4fe5280a28 > and then repeat > > p *$i > p $i =3D $i->right > > until $i is NULL. (gdb) p $i =3D current_buffer->text->intervals $2 =3D (INTERVAL) 0x7f4fe5280a28 (gdb) p *$i $3 =3D { gc_header =3D { v =3D 34955678229, gcaligned =3D 21 '\025' }, total_length =3D 31770, position =3D 16392, left =3D 0x7f4fe5281708, right =3D 0x7f4fe5281748, up =3D { interval =3D 0x7f4fe645cfbd, obj =3D XIL(0x7f4fe645cfbd) }, up_obj =3D true, gcmarkbit =3D false, write_protect =3D false, visible =3D false, front_sticky =3D false, rear_sticky =3D false, plist =3D XIL(0x7f4fe528178b) } (gdb) p igc__balance_intervals $4 =3D false (gdb) p $i =3D $i->right $5 =3D (struct interval *) 0x7f4fe5281748 (gdb) p *$i $6 =3D { gc_header =3D { v =3D 35065123349, gcaligned =3D 21 '\025' }, total_length =3D 9680, position =3D 25284, left =3D 0x7f4fe5282220, right =3D 0x7f4fe5284580, up =3D { interval =3D 0x7f4fe5280a28, obj =3D XIL(0x7f4fe5280a28) }, up_obj =3D false, gcmarkbit =3D false, write_protect =3D false, visible =3D false, front_sticky =3D false, rear_sticky =3D false, plist =3D XIL(0x7f4fe52822a3) } (gdb) p $i =3D $i->right $7 =3D (struct interval *) 0x7f4fe5284580 (gdb) p *$i $8 =3D { gc_header =3D { v =3D 35073341461, gcaligned =3D 21 '\025' }, total_length =3D 4210, position =3D 30022, left =3D 0x7f4fe64ae0b0, right =3D 0x7f4fe5282260, up =3D { interval =3D 0x7f4fe5281748, obj =3D XIL(0x7f4fe5281748) }, up_obj =3D false, gcmarkbit =3D false, write_protect =3D false, visible =3D false, front_sticky =3D false, rear_sticky =3D false, plist =3D XIL(0x7f4fe26e87b3) } (gdb) p $i =3D $i->right $9 =3D (struct interval *) 0x7f4fe5282260 (gdb) p *$i $10 =3D { gc_header =3D { v =3D 35073261589, gcaligned =3D 21 '\025' }, total_length =3D 1748, position =3D 30975, left =3D 0x7f4fe632d920, right =3D 0x7f4fe5283090, up =3D { interval =3D 0x7f4fe5284580, obj =3D XIL(0x7f4fe5284580) }, up_obj =3D false, gcmarkbit =3D false, write_protect =3D false, visible =3D false, front_sticky =3D false, rear_sticky =3D false, plist =3D XIL(0x7f4fe26ebedb) } (gdb) p $i =3D $i->right $11 =3D (struct interval *) 0x7f4fe5283090 (gdb) p *$i $12 =3D { gc_header =3D { v =3D 35073279509, gcaligned =3D 21 '\025' }, total_length =3D 787, position =3D 31293, left =3D 0x7f4fe5284618, right =3D 0x7f4fe5284658, up =3D { interval =3D 0x7f4fe5282260, obj =3D XIL(0x7f4fe5282260) }, up_obj =3D false, gcmarkbit =3D false, write_protect =3D false, visible =3D false, front_sticky =3D false, rear_sticky =3D false, plist =3D XIL(0x7f4fe3c28afb) } (gdb) p $i =3D $i->right $13 =3D (struct interval *) 0x7f4fe5284658 (gdb) p *$i $14 =3D { gc_header =3D { v =3D 35073290261, gcaligned =3D 21 '\025' }, total_length =3D 471, position =3D 31591, left =3D 0x7f4fe545fc20, right =3D 0x7f4fe55283b8, up =3D { interval =3D 0x7f4fe5283090, obj =3D XIL(0x7f4fe5283090) }, up_obj =3D false, gcmarkbit =3D false, write_protect =3D false, visible =3D false, front_sticky =3D false, rear_sticky =3D false, plist =3D XIL(0x7f4fe3c29fab) } (gdb) p $i =3D $i->right $15 =3D (struct interval *) 0x7f4fe55283b8 (gdb) p *$i $16 =3D { gc_header =3D { v =3D 38246400789, gcaligned =3D 21 '\025' }, total_length =3D 179, position =3D 31675, left =3D 0x7f4fe52ba358, right =3D 0x7f4fe5286a28, up =3D { interval =3D 0x7f4fe5284658, obj =3D XIL(0x7f4fe5284658) }, up_obj =3D false, gcmarkbit =3D false, write_protect =3D false, visible =3D false, front_sticky =3D false, rear_sticky =3D false, plist =3D XIL(0x7f4fe3c2a5ab) } (gdb) p $i =3D $i->right $17 =3D (struct interval *) 0x7f4fe5286a28 (gdb) p *$i $18 =3D { gc_header =3D { v =3D 35073301013, gcaligned =3D 21 '\025' }, total_length =3D 95, position =3D 31705, left =3D 0x7f4fe61681b8, right =3D 0x7f4fe52ac5c0, up =3D { interval =3D 0x7f4fe55283b8, obj =3D XIL(0x7f4fe55283b8) }, up_obj =3D false, gcmarkbit =3D false, write_protect =3D false, visible =3D false, front_sticky =3D false, rear_sticky =3D false, plist =3D XIL(0x7f4fe3c2a7eb) } (gdb) p $i =3D $i->right $19 =3D (struct interval *) 0x7f4fe52ac5c0 (gdb) p *$i $20 =3D { gc_header =3D { v =3D 35073731093, gcaligned =3D 21 '\025' }, total_length =3D 60, position =3D 31740, left =3D 0x7f4fe52ba3f0, right =3D 0x7f4fe52ba430, up =3D { interval =3D 0x7f4fe5286a28, obj =3D XIL(0x7f4fe5286a28) }, up_obj =3D false, gcmarkbit =3D false, write_protect =3D false, visible =3D false, front_sticky =3D false, rear_sticky =3D false, plist =3D XIL(0x7f4fe3c2ab1b) } (gdb) p $i =3D $i->right $21 =3D (struct interval *) 0x7f4fe52ba430 (gdb) p *$i $22 =3D { gc_header =3D { v =3D 35073096981, gcaligned =3D 21 '\025' }, total_length =3D 30, position =3D 31736, left =3D 0x7f4fe52c7b50, right =3D 0x7f4fe52c7b90, up =3D { interval =3D 0x7f4fe52ac5c0, obj =3D XIL(0x7f4fe52ac5c0) }, up_obj =3D false, gcmarkbit =3D false, write_protect =3D false, visible =3D false, front_sticky =3D false, rear_sticky =3D false, plist =3D XIL(0x7f4fe52d076b) } (gdb) p $i =3D $i->right $23 =3D (struct interval *) 0x7f4fe52c7b90 (gdb) p *$i $24 =3D { gc_header =3D { v =3D 35073148437, gcaligned =3D 21 '\025' }, total_length =3D 10, position =3D 31745, left =3D 0x7f4fe52d0108, right =3D 0x7f4fe52d0148, up =3D { interval =3D 0x7f4fe52ba430, obj =3D XIL(0x7f4fe52ba430) }, up_obj =3D false, gcmarkbit =3D false, write_protect =3D false, visible =3D false, front_sticky =3D false, rear_sticky =3D false, plist =3D XIL(0x7f4fe52d0c23) } (gdb) p $i =3D $i->right $25 =3D (struct interval *) 0x7f4fe52d0148 (gdb) p *$i $26 =3D { gc_header =3D { v =3D 35073154325, gcaligned =3D 21 '\025' }, total_length =3D 5, position =3D 31752, left =3D 0x7f4fe52d06b8, right =3D 0x7f4fe52d06f8, up =3D { interval =3D 0x7f4fe52c7b90, obj =3D XIL(0x7f4fe52c7b90) }, up_obj =3D false, gcmarkbit =3D false, write_protect =3D false, visible =3D false, front_sticky =3D false, rear_sticky =3D false, plist =3D XIL(0x7f4fe64c0a73) } (gdb) p $i =3D $i->right $27 =3D (struct interval *) 0x7f4fe52d06f8 (gdb) p *$i $28 =3D { gc_header =3D { v =3D 35073135893, gcaligned =3D 21 '\025' }, total_length =3D 1, position =3D 31770, left =3D 0x0, right =3D 0x0, up =3D { interval =3D 0x7f4fe52d0148, obj =3D XIL(0x7f4fe52d0148) }, up_obj =3D false, gcmarkbit =3D false, write_protect =3D false, visible =3D false, front_sticky =3D false, rear_sticky =3D false, plist =3D XIL(0x7f4fe3c2acf3) } (gdb) p $i =3D $i->right $29 =3D (struct interval *) 0x0 (gdb) p *$i Cannot access memory at address 0x0 (gdb)=20 From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 01 20:09:32 2025 Received: (at 79131) by debbugs.gnu.org; 2 Aug 2025 00:09:32 +0000 Received: from localhost ([127.0.0.1]:59308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhzoZ-00027A-1l for submit@debbugs.gnu.org; Fri, 01 Aug 2025 20:09:32 -0400 Received: from mail-pj1-x1036.google.com ([2607:f8b0:4864:20::1036]:57704) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uhzoU-00026X-Aa for 79131@debbugs.gnu.org; Fri, 01 Aug 2025 20:09:28 -0400 Received: by mail-pj1-x1036.google.com with SMTP id 98e67ed59e1d1-3190fbe8536so1287425a91.3 for <79131@debbugs.gnu.org>; Fri, 01 Aug 2025 17:09:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754093360; x=1754698160; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=WohPzm0bgZe47fT+OQeYqtWcbg/z8KzLsoYMSuU8MEY=; b=gSpUAyN2BrdoGNcb8d0wgcieESm1MEFW84lJAFlOnI6pMwZDPZBxISKdPAhgCz/lSQ b3h7D5fgZXRAlCUcp/reWh4gDDP/e1apKx+XczCyfo5hY4JKHWgeA0hF9RwZlArlDJ73 MPkPzkWHnKMGQnpKqxNb8DwpYDTAQCL8LZHwabmBBBnF1fL5X/oVhkiHgxGtS3Of49cM onNA1/0lWytX4CyfOFbb9IKoCt0BT2QlezzzaCGJnDs0V+TzKexz0hqL7YbZmjbhdbR8 k5ttuXnGynq8kfBLgprblsUrmL+Ax90dH+Yp4CsN4lLtar+VU2TwsAT0kDdcuxxJMqM6 XvsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754093360; x=1754698160; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WohPzm0bgZe47fT+OQeYqtWcbg/z8KzLsoYMSuU8MEY=; b=P+++X/u4UW7E6srIUNaLAhVk6jsRwwvDYYHHmW1ljc8/21AZZA0yymgix7lBMlCGUr ktZzhLtxruorqafgj+IebyGt+cicL7ERGoTDvoL5OF9daB3Z7BAApIxhZfr7NP1VuAfP dVHoKGtZtqXd6w8qloLGn1bj+tVHN8I3V/Kb9EU+BNw9Ai/g2eAKrcYPH5eaxNFv+TAO IPw954isZpSjP/itdYW42UFx0cOqhjSSXpHkNIA7CxW1spESUry4NCAG1ysqmIfkVzgu bI03P7pkqnc8gD+ffy4ZanLNcs7c40OjK0F6o7tyXlDgsGxcrW1u5sxyydEU1m+I9Xbz zkBg== X-Forwarded-Encrypted: i=1; AJvYcCVLSN3M247fW3/+Aa41vw4cvd6UC7EYjeJut3KN9WSr3DvKh/1MK2i1t7qJp7cmW7LMqSqvQQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzDhWHrM9Qe9YQ+Z6BB5p3g8CkME8gEkduF2Es+kiuG6PXeUOAn mG4D/8xV58BwlFDr4uiBtAkhPPYUzVT8Bs7nt9oEkMmxbdQVe9jdqgMW X-Gm-Gg: ASbGncuiwMGjcUXRkYERfbdetBQxJtLvtK4VdS7k4NiuHxhnPiqUWWGFrK2zxz8yPjF +ITTSmLBLAiwVrs+z9vLw0ky3qBTEjq8A5nXW7NAPC4iGcbKV8n/uoKP3mZrTwLfnxcG0BUgyWP SfhYmG2S1HIf5ejl0B6vUSIuHrno0BZOjWRsDfc6An2VFsFnTN5vyxrHuBK3Hj4o/oLwWapS8m6 npTOEkFDHNG7dJ6Ulw4J9C0f7ElDe6Nru748iIgSL0waylsY7LglB8AtbFJRCgiK7q6sJDxOJPT 8aF2BkFq1EMYN6ByNPbkaFTR9sU42+VxvP3dwr+kghX7jRKoa/yUgbKF1JTuCpN94LiJnH5Xp7L 8t8P7PhRtMo+fwn7hkTndnYE/2amNGoOxZNNHOG/FMZOTpJusyQwYSeqoFiVil/kDRMOZhjI= X-Google-Smtp-Source: AGHT+IHTBqCDR9kPpcXyN8BokEKj5cNgWwIRSbbQZ4ZVqbfRuCW9YrD9E5FoMtt+fpJeMwmCvneN1Q== X-Received: by 2002:a17:90b:3d91:b0:311:ea13:2e63 with SMTP id 98e67ed59e1d1-321161f1f06mr1779901a91.13.1754093359988; Fri, 01 Aug 2025 17:09:19 -0700 (PDT) Received: from smtpclient.apple (c-24-4-247-194.hsd1.ca.comcast.net. [24.4.247.194]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-b422b7d9dafsm4317378a12.23.2025.08.01.17.09.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Aug 2025 17:09:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\)) Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV From: Yuan Fu In-Reply-To: <86ikj9ueqj.fsf@gnu.org> Date: Fri, 1 Aug 2025 17:09:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <878qk5qvob.fsf@telefonica.net> <86ikj9ueqj.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3826.600.51.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79131 Cc: gerd.moellmann@gmail.com, =?utf-8?Q?=C3=93scar_Fuentes?= , 79131@debbugs.gnu.org, pipcet@protonmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On Jul 30, 2025, at 10:11=E2=80=AFPM, Eli Zaretskii = wrote: >=20 >> Cc: Pip Cet , >> Gerd M=C3=B6llmann >> Date: Wed, 30 Jul 2025 22:18:44 +0200 >> From: =C3=93scar Fuentes via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >>=20 >>=20 >> 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. >>=20 >> Backtrace from the coredump: >>=20 >> (gdb) bt full >> #0 __pthread_kill_implementation (threadid=3D, = signo=3Dsigno@entry=3D11, no_tid=3Dno_tid@entry=3D0) >> at ./nptl/pthread_kill.c:44 >> tid =3D >> ret =3D 0 >> pd =3D >> old_mask =3D {__val =3D {94452575465120}} >> ret =3D >> #1 0x00007f506ce9e9ff in __pthread_kill_internal = (threadid=3D, signo=3D11) >> at ./nptl/pthread_kill.c:89 >> #2 0x00007f506ce49cc2 in __GI_raise (sig=3Dsig@entry=3D11) at = ../sysdeps/posix/raise.c:26 >> ret =3D >> #3 0x000055e773f12db8 in terminate_due_to_signal >> (sig=3Dsig@entry=3D11, backtrace_limit=3Dbacktrace_limit@entry=3D40)= at ../../emacs/src/emacs.c:481 >> #4 0x000055e773f132de in handle_fatal_signal (sig=3Dsig@entry=3D11) = at ../../emacs/src/sysdep.c:1793 >> #5 0x000055e773f132e5 in deliver_thread_signal >> (sig=3Dsig@entry=3D11, handler=3D0x55e773f132d0 = ) at ../../emacs/src/sysdep.c:1785 >> old_errno =3D >> #6 0x000055e774058dec in deliver_fatal_thread_signal (sig=3D11) at = ../../emacs/src/sysdep.c:1805 >> #7 handle_sigsegv (sig=3D11, siginfo=3D, = arg=3D) at ../../emacs/src/sysdep.c:1943 >> fatal =3D >> #8 0x00007f506ce49df0 in () 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 () at = /lib/x86_64-linux-gnu/libc.so.6 >> #12 add_text_properties_1 (start=3D, = start@entry=3D0x1f06a, end=3D,=20 >> end@entry=3D0x1f07a, properties=3D0x7f4fe3c2acc3, = object=3D0x7f4fe645cfbd,=20 >> object@entry=3D0x0, set_type=3Dset_type@entry=3DTEXT_PROPERTY_REPLAC= E, destructive=3Ddestructive@entry=3Dtrue) >> --Type for more, q to quit, c to continue without paging--c >> at ../../emacs/src/textprop.c:1252 >> i =3D 0x0 >> unchanged =3D >> s =3D 31770 >> len =3D 3 >> modified =3D >> first_time =3D >=20 > 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: >=20 >=20 > /* We are at the beginning of interval I, with LEN chars to scan. */ > for (;;) > { > eassert (i !=3D 0); >=20 > if (LENGTH (i) >=3D len) <<<<<<<<<<<<<<<< >=20 > 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. >=20 >> #13 0x000055e77414774b in Fadd_text_properties >> (start=3D0x1f06a, end=3D0x1f07a, properties=3D, = object=3D0x0) at ../../emacs/src/textprop.c:1308 >> #14 Fput_text_property >> (start=3D0x1f06a, end=3D0x1f07a, property=3D, = value=3D, object=3D0x0) >> at ../../emacs/src/textprop.c:1326 >> properties =3D >> #15 0x00007f505801aec2 in = F747265657369742d2d666f6e742d6c6f636b2d6d61726b2d72616e6765732d746f2d666f6= e74696679_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=3D2, args=3D0x7ffd6a2b0e70) = at ../../emacs/src/eval.c:3201 >> count =3D {bytes =3D } >> val =3D >> #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=3D2, args=3D0x7ffd6a2b0f80) = at ../../emacs/src/eval.c:3201 >> count =3D {bytes =3D } >> val =3D >> #19 0x000055e7740c90e9 in funcall_nil (nargs=3D, = args=3D) >> at ../../emacs/src/eval.c:2884 >> #20 0x000055e7740c643d in run_hook_with_args >> (nargs=3D2, args=3D0x7ffd6a2b0f80, funcall=3D0x55e7740c90e0 = ) at ../../emacs/src/eval.c:3061 >> global_vals =3D >> sym =3D 0x2968c2d2eba0 >> val =3D 0x7f4fe52f5c83 >> ret =3D 0x0 >> #21 0x000055e7740c8e8c in Ffuncall (nargs=3D3, args=3D0x7ffd6a2b0f78) = at ../../emacs/src/eval.c:3201 >> count =3D {bytes =3D } >> val =3D >> #22 0x00007f505b7c1d34 in = F7265646973706c61792d2d7072652d7265646973706c61792d66756e6374696f6e73_redi= splay__pre_redisplay_functions_0 () >> at = /home/oscar/dev/emacs/igc/build/src/../native-lisp/31.0.50-3eae311e/preloa= ded/simple-fab5b0cf-fea6411a.eln >> #23 0x000055e7740c8e8c in Ffuncall (nargs=3Dnargs@entry=3D2, = args=3Dargs@entry=3D0x7f505ad28040) >> at ../../emacs/src/eval.c:3201 >> count =3D {bytes =3D } >> val =3D >> #24 0x000055e7740c7742 in Fapply (nargs=3D2, args=3D0x7f505ad28040) = at ../../emacs/src/eval.c:2830 >> i =3D >> funcall_nargs =3D >> funcall_args =3D 0x0 >> spread_arg =3D >> fun =3D 0x2968f6dc91d8 >> sa_avail =3D 16384 >> sa_count =3D {bytes =3D } >> numargs =3D >> retval =3D >> #25 0x000055e77411753a in exec_byte_code >> (fun=3D, args_template=3D, = nargs=3D, args=3D) >> at ../../emacs/src/lisp.h:2306 >> call_nargs =3D 2 >> call_fun =3D >> count1 =3D {bytes =3D } >> val =3D >> call_args =3D 0x7f505ad28040 >> original_fun =3D 0x43d0 >> op =3D 2 >> type =3D >> targets =3D {0x55e773f17ee1 , = 0x55e77411793f , 0x55e77411793a = , 0x55e774117935 , = 0x55e77411731d , 0x55e77411731d = , 0x55e7741178f7 , = 0x55e7741178b9 , 0x55e7741198e2 = , 0x55e7741198dd , = 0x55e7741198d8 , 0x55e7741198d3 = , 0x55e774117357 , = 0x55e774117360 , 0x55e7741198c6 = , 0x55e7741198e7 , = 0x55e77411976e , 0x55e774119769 = , 0x55e774119764 , = 0x55e77411975f , 0x55e7741172b9 = , 0x55e7741172c0 , = 0x55e774119745 , 0x55e774119752 = , 0x55e7741196f3 , = 0x55e7741196ee , 0x55e7741196e9 = , 0x55e7741196e4 , = 0x55e7741175ef , 0x55e7741175f0 = , 0x55e774119705 , = 0x55e7741196f8 , 0x55e7741196c5 = , 0x55e7741196c0 , = 0x55e7741196bb , 0x55e7741196b6 = , 0x55e7741173bd , = 0x55e7741173c0 , 0x55e7741196d7 = , 0x55e7741196ca , = 0x55e774119697 , 0x55e774119692 = , 0x55e77411968d , = 0x55e774119688 , 0x55e774117639 = , 0x55e774117640 , = 0x55e7741196a9 , 0x55e77411969c = , 0x55e774119273 , = 0x55e7741192a7 , 0x55e774119330 = , 0x55e773f17ee1 , = 0x55e773f17ee1 , 0x55e773f17ee1 = , 0x55e773f17ee1 , = 0x55e773f17ee1 , 0x55e7741190c7 = , 0x55e774119054 , = 0x55e77411900d , 0x55e774118fc6 = , 0x55e774118f81 , = 0x55e7741197ef , 0x55e7741197af = , 0x55e774118f4f , = 0x55e77411984b , 0x55e774119773 = , 0x55e774118f0f , = 0x55e774118edf , 0x55e774118e9f = , 0x55e774118e62 , = 0x55e774118e21 , 0x55e774118dab = , 0x55e774118d20 , = 0x55e774118c8b , 0x55e774118c5b = , 0x55e774118c2b , = 0x55e774118beb , 0x55e774118bab = , 0x55e774118b6b , = 0x55e774118b27 , 0x55e774118aed = , 0x55e774118ab3 , = 0x55e774118a79 , 0x55e7741189d7 = , 0x55e77411897b , = 0x55e774118921 , 0x55e7741188c7 = , 0x55e77411886d , = 0x55e774118813 , 0x55e7741187b9 = , 0x55e774118761 , = 0x55e774118704 , 0x55e7741186ac = , 0x55e774118654 , = 0x55e7741185fc , 0x55e7741185a3 = , 0x55e7741184b2 , = 0x55e774117689 , 0x55e774118482 = , 0x55e77411844d , = 0x55e7741183bd , 0x55e774118373 = , 0x55e774118343 , = 0x55e774118311 , 0x55e7741182df = , 0x55e7741182a5 , = 0x55e774118273 , 0x55e773f17ee1 = , 0x55e774118241 , = 0x55e77411820f , 0x55e7741181dd = , 0x55e7741181ab , = 0x55e774118179 , 0x55e774118149 = , 0x55e774117689 , = 0x55e773f17ee1 , 0x55e774118105 = , 0x55e7741180d4 , = 0x55e7741180a3 , 0x55e774118062 = , 0x55e774118021 , = 0x55e774117ff0 , 0x55e774117fbf = , 0x55e774117f7e , = 0x55e774117f3d , 0x55e774117efc = , 0x55e774117ec9 , = 0x55e774117e98 , 0x55e773f17ee1 = , 0x55e77411943f , = 0x55e774119615 , 0x55e774119887 = , 0x55e7741195d6 , = 0x55e77411959a , 0x55e77411955e = , 0x55e77411949d , = 0x55e774119478 , 0x55e774119712 = , 0x55e77411941a , = 0x55e7741193b7 , 0x55e774119382 = , 0x55e77411933b , = 0x55e77411921e , 0x55e7741191da = , 0x55e774119190 , = 0x55e774119125 , 0x55e773f17ee1 = , 0x55e774117e53 , = 0x55e774117e22 , 0x55e774117df1 = , 0x55e774117dc0 , = 0x55e774117d8f , 0x55e774117d4e = , 0x55e774117d0d , = 0x55e774117ccc , 0x55e774117c8b = , 0x55e774117c24 , = 0x55e774117be3 , 0x55e774117ba2 = , 0x55e774117b71 , = 0x55e774117b25 , 0x55e774117ad9 = , 0x55e774117a9b , = 0x55e774117a5d , 0x55e774117a22 = , 0x55e77411854b , = 0x55e7741184fc , 0x55e7741179b2 = , 0x55e774117944 , = 0x55e773f17ee1 , 0x55e773f17ee1 = , 0x55e773f17ee1 , = 0x55e773f17ee1 , 0x55e773f17ee1 = , 0x55e773f17ee1 , = 0x55e774118ddb , 0x55e774118a33 = , 0x55e774118407 , = 0x55e774117873 , 0x55e77411782d = , 0x55e773f17ee1 , = 0x55e773f17ee1 , 0x55e7741177f4 = , 0x55e774117790 , = 0x55e773f17ee1 , 0x55e773f17ee1 = , 0x55e773f17ee1 , = 0x55e773f17ee1 , 0x55e773f17ee1 = , 0x55e773f17ee1 , = 0x55e773f17ee1 , 0x55e773f17ee1 = , 0x55e774117756 } >> quitcounter =3D >> bc =3D 0x55e7742cb858 >> top =3D 0x7f505ad28038 >> pc =3D >> bytestr =3D >> vector =3D >> maxdepth =3D >> const_length =3D >> bytestr_length =3D >> vectorp =3D 0x7f506b0a53f0 >> max_stack =3D >> frame_base =3D >> fp =3D >> bytestr_data =3D >> rest =3D >> mandatory =3D >> nonrest =3D >> pushedargs =3D >> saved_quitcounter =3D 0 '\000' >> saved_vectorp =3D 0xdd98 >> saved_bytestr_data =3D 0x7ffd00000002 >> result =3D >> #26 0x000055e7740c8e8c in Ffuncall (nargs=3Dnargs@entry=3D2, = args=3Dargs@entry=3D0x7ffd6a2b1290) >> at ../../emacs/src/eval.c:3201 >> count =3D {bytes =3D } >> val =3D >> #27 0x000055e7740c5dbe in internal_condition_case_n >> (bfun=3Dbfun@entry=3D0x55e7740c8d90 , = nargs=3Dnargs@entry=3D2, args=3Dargs@entry=3D0x7ffd6a2b1290, = handlers=3Dhandlers@entry=3D0x38, hfun=3Dhfun@entry=3D0x55e773f4e550 = ) at ../../emacs/src/eval.c:1793 >> val =3D >> c =3D 0x55e77bd0b710 >> #28 0x000055e773f3bc04 in dsafe__call >> (inhibit_quit=3Dinhibit_quit@entry=3Dtrue, f=3D0x55e7740c8d90 = , nargs=3Dnargs@entry=3D2, args=3Dargs@entry=3D0x7ffd6a2b1290) = at ../../emacs/src/xdisp.c:3106 >> count =3D {bytes =3D } >> redisplay_counter_before =3D 939536 >> val =3D >> #29 0x000055e773f6efbe in dsafe__call (inhibit_quit=3Dtrue, nargs=3D2, = f=3D, args=3D0x7ffd6a2b1290) >> at ../../emacs/src/xdisp.c:3094 >> val =3D >> count =3D {bytes =3D } >> redisplay_counter_before =3D >> #30 prepare_menu_bars () at ../../emacs/src/xdisp.c:14060 >=20 > 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? >=20 > 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=3Dnil so redisplay will re-fontify them. If = that=E2=80=99s of any help. Yuan= From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 03 09:34:36 2025 Received: (at 79131) by debbugs.gnu.org; 3 Aug 2025 13:34:36 +0000 Received: from localhost ([127.0.0.1]:43276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uiYrD-0005Ha-9u for submit@debbugs.gnu.org; Sun, 03 Aug 2025 09:34:35 -0400 Received: from mail-24418.protonmail.ch ([109.224.244.18]:17223) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uiYr9-0005H6-2M for 79131@debbugs.gnu.org; Sun, 03 Aug 2025 09:34:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1754228064; x=1754487264; bh=NjtzZ4wORk/CHd36ObvGutrOJ2CpcRf3U/mjB0/vMT8=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=zNc+o4UHh01nHvY+suftwzdcHeG9fFzRGjNF9IC4uOo/9A5lsePLvM7RnjwJK7TEe KfQHlvRq3P3/Z8exJba2E7eKysB8UFos2HPy90/amkSswdN9+XbaQsAqP1fHv2OVuo r4bfnTS0TyPlmvfT8X7ieeoN8qQj6uFcZA536IpLz551SPE91JCDy8Tt/1dn/wVMhz pub2zQVnr6yEnza1G/h55n1GXNWObtVWHApENrnFL+de/6QyNqbklkf4xX3C13fdGA Pn+Ws0uTg+s41fUnKMT9B0GK8qLhkrjlB0Vz+4p6kFAedPUt1uITt0HQ0UDxNBYmaY Z9rCaL643dgQw== Date: Sun, 03 Aug 2025 13:34:18 +0000 To: =?utf-8?Q?=C3=93scar_Fuentes?= From: Pip Cet Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Message-ID: <87v7n4a5sf.fsf@protonmail.com> In-Reply-To: <87tt2spv7t.fsf@telefonica.net> References: <878qk5qvob.fsf@telefonica.net> <86ikj9ueqj.fsf@gnu.org> <87tt2spv7t.fsf@telefonica.net> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: f8941d15f05771c31a0d8e0b18fe0d859857c0c1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79131 Cc: gerd.moellmann@gmail.com, Eli Zaretskii , 79131@debbugs.gnu.org, Yuan Fu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) =C3=93scar Fuentes writes: > Eli, Gerd, Pip: > > Eli Zaretskii writes: > >>> #12 add_text_properties_1 (start=3D, start@entry=3D0x1f0= 6a, end=3D, >>> end@entry=3D0x1f07a, properties=3D0x7f4fe3c2acc3, object=3D0x7f4fe6= 45cfbd, >>> object@entry=3D0x0, set_type=3Dset_type@entry=3DTEXT_PROPERTY_REPLA= CE, destructive=3Ddestructive@entry=3Dtrue) >>> --Type for more, q to quit, c to continue without paging--c >>> at ../../emacs/src/textprop.c:1252 >>> i =3D 0x0 >>> unchanged =3D >>> s =3D 31770 >>> len =3D 3 >>> modified =3D >>> first_time =3D >> >> 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 !=3D 0); >> >> if (LENGTH (i) >=3D 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 =E2=80=98simple.el= =E2=80=99. > > 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=C3=B6llmann 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 !=3D 0); >> 1255 >> 1256 if (LENGTH (i) >=3D 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=C3=B6llmann writes: > >> Gerd M=C3=B6llmann writes: >> >>> I'm in the process of merging master, BTW. >> >> Done. > > Thanks! > > > Pip Cet 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=3Dmake_fixnum(31770= ), end=3Dmake_fixnum(31774), > properties=3D, object=3DXIL(0)) at ../../emacs/src/tex= tprop.c:1308 > 1308 return add_text_properties_1 (start, end, properties, object, > (gdb) p *current_buffer->text > $1 =3D { > beg =3D 0x55e77e157f80 "", > gpt =3D 1, > z =3D 31775, I think Z =3D 31775 should mean that the interval tree covers 31775 characters. > (gdb) p $i =3D current_buffer->text->intervals > $2 =3D (INTERVAL) 0x7f4fe5280a28 > (gdb) p *$i > $3 =3D { > gc_header =3D { > v =3D 34955678229, > gcaligned =3D 21 '\025' > }, > total_length =3D 31770, But the interval tree only covers 31770 characters. > (gdb) p *$i > $28 =3D { > gc_header =3D { > v =3D 35073135893, > gcaligned =3D 21 '\025' > }, > total_length =3D 1, > position =3D 31770, > left =3D 0x0, > right =3D 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 From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 03 10:06:10 2025 Received: (at 79131) by debbugs.gnu.org; 3 Aug 2025 14:06:10 +0000 Received: from localhost ([127.0.0.1]:44994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uiZLm-00029J-E9 for submit@debbugs.gnu.org; Sun, 03 Aug 2025 10:06:10 -0400 Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:47276) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uiZLk-00028k-5R for 79131@debbugs.gnu.org; Sun, 03 Aug 2025 10:06:08 -0400 Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-3b7920354f9so3408753f8f.2 for <79131@debbugs.gnu.org>; Sun, 03 Aug 2025 07:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754229961; x=1754834761; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=VuV2V4N+uAVPWRfzHp6tyj4vHFbe1R5LT/khEvcUAWg=; b=QxaGaUyx2FJEsQOjqqWKVkJe7BYvjNHC1bRxD4xK/deIGIdRsQRaACBA0Jj86mZzK8 4fQ+TAjrJdJTv1PlwmbVzkaQi9SX9ZvqnlOQDHvsvyzdHskGjRan02VERHkAvqc4zxqb leIdcrNMkJTioBSha2uQe3xIAfxi6Ky5LcCqNrnA1GNQE1j87QtH1bzLCsYdSrYp3lXm bSCYvM8YW884cb8N4JrqNLb2zGUEiwSLb3Fd1qK76GPLSuzae5KE8KP2B4FaWkVi52mr chGui1/b49U6YMDQr0t6hlt32zxEJ/IQV4jBu58NsdAPfMh7FadhDimMnCEVjGxT0FeH 04pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754229961; x=1754834761; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VuV2V4N+uAVPWRfzHp6tyj4vHFbe1R5LT/khEvcUAWg=; b=YPxf1Tla1lULejTz6efpj+DbenFrOOsbaYPmuq4jZmWUkpOb1WaBk4vf9iZzyOJoyB VFfs7PGLlFvCqeefbH94CTvgOKFGfcmia9QPQzPC/zfSdEhds7mjb34y/JRDL5S+B93D 0hxo6HzIUR0QMsQKAGvHq7Upk2ucyioXCtjWJ05uK7w8iDiDn20LR/6CRfp/UIIWRInL wkgVko8MNgBm49u0uOqJxzqziIWhgaDLfuStaOb4AkUWJJgtyGZ0F7N+Iy09jnlDi83L lySp7+qXQZRaqbIJ+33HpyXo9877SiP1jzi9h1AeJ3jgFIhSUz5WcTszMlo2hDteO5oN MmGA== X-Forwarded-Encrypted: i=1; AJvYcCWo8k4eialed1MJOqF/BH+JcSqyLjrL7dwRCbQmbRvCZaZbhvCyEUJ1jEEdfzjPqhMOKjySKg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyKh0siK/ty44viJhbUFUw7m05pYj752TM/kENhpa8sDDE7cZnI EPZECQk0TrqFCZgQVTtgA3SQBLsBXKJGXATT45IXh8Ut3SzMQP/zmq+7n1+Oa3ii X-Gm-Gg: ASbGncumSd62iuN4DBMmCT3he0OKl6E6saDCfEWvsmNxU+lyTazM/htlvRafCWH0skO qV5dlSEDHD0UJdUuO6q2crYoP4dd2w2UqX9Z78GWOVsSoDETV+cpnYCNpi4/SisZsHI8Dg5Kv73 KB521elYqTQpMQwMI/G0PqVpehbjX5EQuygzYJoFS8tY553WsCmZB749POuCRF2oZVsuIatGO6K xllTBfwMuQTwwvaXdI1DOS3QP5xcYjpTa5gJlA+W/fT8H3KCENEyzgPd3xgLGpWLwzeprPq9UIl rVdfIuJ2mPefctxWSHK+TcYGZ8w/2hDDi4ps6g/KNtfwlNEhPqlnLV7s4N/CC81u1wcP1FUn+EN AbNyakFjUHhnKnBEj1U+fB+ZvgmSYlEmdlxhEK4B0mOBttjPI69E/EgSiOVJf8FIKZWeq4LxsY0 9djJCO0GLhorjU4tVKexvCsq1oC7nbUprb7FU= X-Google-Smtp-Source: AGHT+IGCPdA4SfinKiQ87PtEoOiP0yquX9/T16YEPXxGQMrC/iYwVfHy4gcWnTHg/F9zMZBdIjV2FA== X-Received: by 2002:a5d:5f82:0:b0:3a4:f7e6:2b29 with SMTP id ffacd0b85a97d-3b8d94684f6mr4956433f8f.5.1754229961444; Sun, 03 Aug 2025 07:06:01 -0700 (PDT) Received: from pro2 (p200300e0b70e8b002124748d09eedd4d.dip0.t-ipconnect.de. [2003:e0:b70e:8b00:2124:748d:9ee:dd4d]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3b79c47b10asm12117898f8f.60.2025.08.03.07.06.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Aug 2025 07:06:00 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Pip Cet Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV In-Reply-To: <87v7n4a5sf.fsf@protonmail.com> References: <878qk5qvob.fsf@telefonica.net> <86ikj9ueqj.fsf@gnu.org> <87tt2spv7t.fsf@telefonica.net> <87v7n4a5sf.fsf@protonmail.com> Date: Sun, 03 Aug 2025 16:06:00 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79131 Cc: =?utf-8?Q?=C3=93scar?= Fuentes , Eli Zaretskii , 79131@debbugs.gnu.org, Yuan Fu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet 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: 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 03 10:46:59 2025 Received: (at 79131) by debbugs.gnu.org; 3 Aug 2025 14:46:59 +0000 Received: from localhost ([127.0.0.1]:45065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uiZzH-0004S4-7O for submit@debbugs.gnu.org; Sun, 03 Aug 2025 10:46:59 -0400 Received: from mail.eclipso.de ([217.69.254.104]:60098) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uiZzC-0004RU-NC for 79131@debbugs.gnu.org; Sun, 03 Aug 2025 10:46:56 -0400 X-ESMTP-Authenticated-User: 000D6BEA From: =?utf-8?Q?=C3=93scar_Fuentes?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclipso.de; s=mail; t=1754232408; bh=4vppq1aqzqzoYCcO/QBkiBAJmjjpleIsS0C9zOBOrHA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Q8R+iui9AoH3B4LzLi/wrl2UeiVp8+OEMOyr+KcoKxCUYNeljURw6tflaNhftqTVN 7kkRQwRJtrRWilhQ4Vd0rWPhCEMC0bJxaabVJFOw6kIX2na9ZNXvBRCU8PI+7CORvd crVZ3q3Ly5LXFsvRDfPAswmLnKHHI/lCUJKFZWjA1Gh/GRZpY8bQeih4Htd2u0tKn9 G7qdeltrduQHaLzdcSUeEFGLGfgL8dLv+ciZg+I6+IrqNxdkAS/EVtresdAXUjZtiY 58h6mQpuyn51SgTsyOABOZ0EDbNJhC7g+3mKYBCOHYn/6Puoq8oqApw4zMDd7f4gci a6onarhVJ3fsg== To: Pip Cet Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV In-Reply-To: <87v7n4a5sf.fsf@protonmail.com> References: <878qk5qvob.fsf@telefonica.net> <86ikj9ueqj.fsf@gnu.org> <87tt2spv7t.fsf@telefonica.net> <87v7n4a5sf.fsf@protonmail.com> Date: Sun, 03 Aug 2025 16:46:47 +0200 Message-ID: <87y0s0wjhk.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79131 Cc: gerd.moellmann@gmail.com, Eli Zaretskii , 79131@debbugs.gnu.org, Yuan Fu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Pip Cet writes: > So can you try > > p current_buffer->pt (gdb) fr 13 #13 0x000055e77414774b in Fadd_text_properties (start=0x1f06a, end=0x1f07a, properties=, 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 > p current_buffer->beg + 1153 + 31770 - 64 (gdb) p current_buffer->text->beg + 1153 + 31770 - 64 $4 = (unsigned char *) 0x55e77e15ffdb 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 03 10:47:49 2025 Received: (at 79131) by debbugs.gnu.org; 3 Aug 2025 14:47:49 +0000 Received: from localhost ([127.0.0.1]:45071 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uia04-0004UT-St for submit@debbugs.gnu.org; Sun, 03 Aug 2025 10:47:49 -0400 Received: from mail-24418.protonmail.ch ([109.224.244.18]:31659) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uia01-0004U7-2S for 79131@debbugs.gnu.org; Sun, 03 Aug 2025 10:47:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1754232458; x=1754491658; bh=lkj4vszKgjw/G/TSQn0aElhmNpv7dC0P9TIHpbYN+FI=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=rqNCcUSoKzydgEFfcdvEs3fiOFvoN6BD9JZzg12Qg8quxB+32uCVizsgqC6xQTaew 0mgqT7YrHBXhU9VdeznzB/bmmxoEQ2HhfAwLWdIQ7W3vKiIt0o6bjZlOHYUxC+6TzW 3xoR/pSt0I857rWYPPOlcYD2O3n0TA2IcEix+u6swnkiE2samiI6VlHz0ib2atXRaL Ga9U8MmtR4qkCmIvZDj8VaE3GQrrL37BcyFl2YQq/5FGiqNHPgYAMHv3KCG/CN3lZk YIe177Tq6HnQedoQczo0nukNEThLFoTEgRGvQhlaN8Y4zpMBbWpQuXhCG9i3HD9Ck9 0rDljMMuQofEQ== Date: Sun, 03 Aug 2025 14:47:29 +0000 To: =?utf-8?Q?=C3=93scar_Fuentes?= From: Pip Cet Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Message-ID: <87jz3ka2eh.fsf@protonmail.com> In-Reply-To: <87tt2spv7t.fsf@telefonica.net> References: <878qk5qvob.fsf@telefonica.net> <86ikj9ueqj.fsf@gnu.org> <87tt2spv7t.fsf@telefonica.net> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 81056dca5a6a34220d775524efc37827c6050e35 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.0 (-) X-Debbugs-Envelope-To: 79131 Cc: gerd.moellmann@gmail.com, Eli Zaretskii , 79131@debbugs.gnu.org, Yuan Fu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.0 (--) Pip Cet writes: > =C3=93scar Fuentes writes: > >> Eli, Gerd, Pip: >> >> Eli Zaretskii writes: >> >>>> #12 add_text_properties_1 (start=3D, start@entry=3D0x1f= 06a, end=3D, >>>> end@entry=3D0x1f07a, properties=3D0x7f4fe3c2acc3, object=3D0x7f4fe= 645cfbd, >>>> object@entry=3D0x0, set_type=3Dset_type@entry=3DTEXT_PROPERTY_REPL= ACE, destructive=3Ddestructive@entry=3Dtrue) >>>> --Type for more, q to quit, c to continue without paging--c >>>> at ../../emacs/src/textprop.c:1252 >>>> i =3D 0x0 >>>> unchanged =3D >>>> s =3D 31770 >>>> len =3D 3 >>>> modified =3D >>>> first_time =3D >>> >>> 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 !=3D 0); >>> >>> if (LENGTH (i) >=3D 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 =E2=80=98simple.el= =E2=80=99. >> >> 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=C3=B6llmann writes: >> >>> That would be around here >>> >>> textprop.c: >>> 1251 /* We are at the beginning of interval I, with LEN chars to sca= n. */ >>> 1252 for (;;) >>> 1253 { >>> 1254 eassert (i !=3D 0); >>> 1255 >>> 1256 if (LENGTH (i) >=3D len) >>> 1257 { >>> >>> and that probably means i is NULL, which is a pointer to an interval. I= t >>> 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=C3=B6llmann writes: >> >>> Gerd M=C3=B6llmann writes: >>> >>>> I'm in the process of merging master, BTW. >>> >>> Done. >> >> Thanks! >> >> >> Pip Cet 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=3Dmake_fixnum(3177= 0), end=3Dmake_fixnum(31774), >> properties=3D, object=3DXIL(0)) at ../../emacs/src/te= xtprop.c:1308 >> 1308 return add_text_properties_1 (start, end, properties, object, >> (gdb) p *current_buffer->text >> $1 =3D { >> beg =3D 0x55e77e157f80 "", >> gpt =3D 1, >> z =3D 31775, > > I think Z =3D 31775 should mean that the interval tree covers 31775 > characters. > >> (gdb) p $i =3D current_buffer->text->intervals >> $2 =3D (INTERVAL) 0x7f4fe5280a28 >> (gdb) p *$i >> $3 =3D { >> gc_header =3D { >> v =3D 34955678229, >> gcaligned =3D 21 '\025' >> }, >> total_length =3D 31770, > > But the interval tree only covers 31770 characters. > >> (gdb) p *$i >> $28 =3D { >> gc_header =3D { >> v =3D 35073135893, >> gcaligned =3D 21 '\025' >> }, >> total_length =3D 1, >> position =3D 31770, >> left =3D 0x0, >> right =3D 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 =3D 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 From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 03 10:51:06 2025 Received: (at 79131) by debbugs.gnu.org; 3 Aug 2025 14:51:06 +0000 Received: from localhost ([127.0.0.1]:45078 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uia3G-0004im-25 for submit@debbugs.gnu.org; Sun, 03 Aug 2025 10:51:06 -0400 Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]:60587) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uia3B-0004i2-GX for 79131@debbugs.gnu.org; Sun, 03 Aug 2025 10:51:04 -0400 Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-459d40d16bdso3517725e9.0 for <79131@debbugs.gnu.org>; Sun, 03 Aug 2025 07:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754232655; x=1754837455; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=hvhOFFBWenKtuTLLK7A9UzKa4hYfdIm245zGCdnIZIE=; b=Jv3a50TZLC9yOxvvz6YuPAOA7hgQlsecqBc/zRz/i57Ze8oKEJySkOIbEPfE/N5AOl msEG3zwdcgFAUTJwL6vFli0NujazY8uO9XtOaA752YRyrGys8TQurmWnEWD6j6ESytOB JqBhq9TORxlI4ag8AkDRSdQF99eNpNKsUxdJJPbJKSsUUwOgnex93AG3WKWNBp8MeGiC z9S8KQgePUkcniUAj8wjPUH6FefRvu8V7dH/emNoCSBHpuSDvMxuK1oV7E3K/RNUvyBc Il1N3RGS6+y7TRRvVR+ik02cHf1F7+SIzNNpBD7bt9xUNIb4hjduXb0rO84wv45jjA1Y Pr/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754232655; x=1754837455; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hvhOFFBWenKtuTLLK7A9UzKa4hYfdIm245zGCdnIZIE=; b=OcOOdCHu23gYjett6W9C1aeBOA3Nn1E+1kYY3BF8ajbJuoW8dhPSdhOMMoua2yezUM G5P3qxLzYqyPIra8iz3yjNa7jUcsKURNLM6a277ziBM3YdPFAj2+BO3tCZeLNMWvR45I SfsXQCsb3uF7vjfZDzViXK/5rOkXDpX2CgXIp0GqvtZpHdjU56vmMK2aZGUkTndBN5pD QPIwHntSd0l974IMiZwy1wnOYrdklB8wiFpCWc6IH9vbQMwLvnfRPwkZWQBJFoUg5CMm LtzZ2DxD1pNlRIiO405vIvpOrpmDZvOAsqdLeLxsx1ck+GFxWXWjM25MzlAUwaYdLdeP XOcA== X-Forwarded-Encrypted: i=1; AJvYcCUp4Eu81lpOFAlFoWj7pt0HDPsZzCMhQkjSHs36JkqDdVESKwKv+obqREsm67arMapsMUrG1Q==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzJUYLzm5y8MQ/R2j7hUxKh28R8sXvkgBtHuQVOyNeFc2QAUIup 9XDwLP95fDTwct/40TesFb3XY6xu8+FhvxTB90Env40rEWPyQY8xgHe75qms4Sq0 X-Gm-Gg: ASbGnct45tWVG9QtuFt/DfAYZjuWSf4wMSceY+GudbRdpMgGLy27tfoEx9UVhg2cF97 nZzz9a8UiNf29/251I/Sdr1qN9KXmiXWF5cezduBzs6AOqXhftOSORQWqOoqUPhEapofF2dOW+X z0oT7IFoSrI1lD2fZPmSKDufzf5bZCr0hvbnfZroZkRrMoFJRhJkz++tKslTLqnkNwrsEGPRxcc F6on835KLLpgaZuYIcOwvLI4odVOt2EA4J+6sY/a3NVeq0DI1+Ou4xqri/wkgLlM6h1q5chEX88 bhqrdKk+1da+87ROeguf/2SX/USxSWBzNh/mNn4ePC8PPmMc1gQ5aMtlnFszeKfJITbOcOM8Bap JUaSKTRnytLagP9YMitTibdBxh/GGMyB0izwNYKzg/Y/cT3WO35GUDUIxOURqwMfgfCgd9AkkeX 8jt1lVwuCxAgKjBltt2BAi+jny1PGDQQ6Zob0= X-Google-Smtp-Source: AGHT+IFLNWa5SNgpdwKGhpRP0xwl4RifHNuLHAegvmWlsvmAuUctlWAHL1Qs0CiAZCVAirCzoMah4A== X-Received: by 2002:a05:600c:3113:b0:456:1560:7c63 with SMTP id 5b1f17b1804b1-458b69f2387mr48227185e9.3.1754232654942; Sun, 03 Aug 2025 07:50:54 -0700 (PDT) Received: from pro2 (p200300e0b70e8b002124748d09eedd4d.dip0.t-ipconnect.de. [2003:e0:b70e:8b00:2124:748d:9ee:dd4d]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3b79c3ac115sm12474195f8f.12.2025.08.03.07.50.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Aug 2025 07:50:54 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Pip Cet Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV In-Reply-To: <87jz3ka2eh.fsf@protonmail.com> References: <878qk5qvob.fsf@telefonica.net> <86ikj9ueqj.fsf@gnu.org> <87tt2spv7t.fsf@telefonica.net> <87jz3ka2eh.fsf@protonmail.com> Date: Sun, 03 Aug 2025 16:50:53 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79131 Cc: =?utf-8?Q?=C3=93scar?= Fuentes , Eli Zaretskii , 79131@debbugs.gnu.org, Yuan Fu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet 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! From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 03 10:58:49 2025 Received: (at 79131) by debbugs.gnu.org; 3 Aug 2025 14:58:49 +0000 Received: from localhost ([127.0.0.1]:45097 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uiaAi-0005AR-U3 for submit@debbugs.gnu.org; Sun, 03 Aug 2025 10:58:49 -0400 Received: from mail-10628.protonmail.ch ([79.135.106.28]:12677) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uiaAg-00059w-Ru for 79131@debbugs.gnu.org; Sun, 03 Aug 2025 10:58:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1754233119; x=1754492319; bh=UDyklnnSH++AMgnEZXp2CY1ckMbR4ErDs0096FW9v9I=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=c70hN7O8Phel5T6A8fZm0BJ+Htfa3yJacDSlKLRjgzn8ieYzSJexzjJ3yaWNapvF7 XjOIClzoD68QhTQ0GNb0Jnm/Gzb964NKCUQueQZice4yAo478b6xQZUBFkZ7LiuJNB tDpaoycibTn3+rUhZopbJwyjQwvxx35e2ch20QoSYyD2Db35Hp6MWFDLtz4MwiaelW ZmBxXjUamR0u8aGbKGMW+yPfsICOTj7/KqAtaF2BdjIWPd/RmpCXYiFEPEaVSNmaaw VDLH9Ai+53d7mCf+2AlzBoMWp7x/8dO3rzVFTg+o7sv95biEpJ+hXXvsuTnqCiU7jO hCj3P4I1Og4ug== Date: Sun, 03 Aug 2025 14:58:34 +0000 To: =?utf-8?Q?=C3=93scar_Fuentes?= From: Pip Cet Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Message-ID: <87bjowa1w0.fsf@protonmail.com> In-Reply-To: <87y0s0wjhk.fsf@telefonica.net> References: <878qk5qvob.fsf@telefonica.net> <86ikj9ueqj.fsf@gnu.org> <87tt2spv7t.fsf@telefonica.net> <87v7n4a5sf.fsf@protonmail.com> <87y0s0wjhk.fsf@telefonica.net> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: cf5b33342a45d1b52922a087f3c4869dd9702115 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.0 (-) X-Debbugs-Envelope-To: 79131 Cc: gerd.moellmann@gmail.com, Eli Zaretskii , 79131@debbugs.gnu.org, Yuan Fu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.0 (--) =C3=93scar Fuentes writes: > Pip Cet writes: > >> So can you try >> >> p current_buffer->pt > > (gdb) fr 13 > #13 0x000055e77414774b in Fadd_text_properties (start=3D0x1f06a, end=3D0x= 1f07a, properties=3D, > object=3D0x0) at ../../emacs/src/textprop.c:1308 > 1308 return add_text_properties_1 (start, end, properties, object, > (gdb) p current_buffer->pt > $1 =3D 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 =3D (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 From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 03 11:10:38 2025 Received: (at 79131) by debbugs.gnu.org; 3 Aug 2025 15:10:38 +0000 Received: from localhost ([127.0.0.1]:45151 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uiaMA-00063P-6b for submit@debbugs.gnu.org; Sun, 03 Aug 2025 11:10:38 -0400 Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]:51216) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uiaM4-00062y-UQ for 79131@debbugs.gnu.org; Sun, 03 Aug 2025 11:10:35 -0400 Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-3b788feab29so1864737f8f.2 for <79131@debbugs.gnu.org>; Sun, 03 Aug 2025 08:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754233826; x=1754838626; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=Fh6HjW61sfvE4YmTODXppdrtFstZuUtLkCCC+DhX7NE=; b=kKno/LXbbrm4iDphXzOTYqyd2d50sSMTBzevLhpIwvB947Cp0tCFmM7ISoSjlpBfvS ItwtflcHd+aylIm1294KKy2NfNGfTdnmNi9r0S2cGMg47gy34LDEMAXJGzBstBcCJe9/ PTAKgfv8nqfbbZbaaRy/GYm5teyA5cZbkmyO5ItGfk5cRAOe9AwZMJhaxdDz2flatWkC HrAcOq9mW3PryKGs/2U4Z0HrRNDUfli4RunsLCfsaImhNtdZDSAO3mXdBsNmxiqYP2FZ jAVekNUVdm71g6xg3LB1r/2t3hdFimjVHbnJDcvlT94JhEI0j5LuFfkYpXKOm7eMyKPi sr8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754233826; x=1754838626; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Fh6HjW61sfvE4YmTODXppdrtFstZuUtLkCCC+DhX7NE=; b=wB92fydnNTtpLxQFxPG+hP7vSEKsrmxOtOC4S0EvQ4FlnIP6zvQ0eAcB1K/mWoN8oo iSJXfJsGcaBbbI64LmQdHzVGZZ/4yaD0TvqJR0JBTFFlEt9jBaLjGaX60+GG1Jtas8Qb gge/W8FJHulrwGvkxt8aQ56OFtwqV0fArCwz9jFxKeQM2S8BvXe2SuF3Sn3Jf5Uzsh8e l3v6T5JJacIOlrpcT8X0enkeRKJT+DdQT6sZmf7zIJ2OrPKBB5CZVsn4XNU4YQcK3AM5 nlUN79Ih+Q6lqHUsgeBx9z2IgoAHVEkDjmQvxYWVQrFniJ2LvWSnSRYOA7wTLPNwsByN Bw/w== X-Forwarded-Encrypted: i=1; AJvYcCXsGzXwHgqp/jlIWlom1TEeIUYK1P9iQQnuP/oVlnlrFY/iTNQ3rxBpgW/LcgNbuL+vQz0y2Q==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yytq88f0Sdm0vnJMREHF0tJTLgHMdLiB8XqIvDQgd7pIh1H22+U Ouu5474XHsnUlUypLqRnC/dEaEcP/26DsBwmtFvyxw7Q8XO1a5H4Mfb6eaei+KMK X-Gm-Gg: ASbGncuvny/UQsehwQUzedpbTbUthmKkZOF7+rKPHqX94YzTYH2ZA+d5oXEDFbgsS+5 8fM0Jmmk9l6xtZ7UXEdgIrvbMqfkkrSAmwFJ4iReewTkGm6If+edrMANxXN8iBvrM6eThvJtX9Q z9ksUskp/KMxy3Wg9TZfO+BO1AYRTgHmL02wcGGPTRMWYCI85pTGNBR/iHhYbtYbniCp+2pKnRm UVNCXZRH99oRLs4twmAq+4k66Jdx+LEjxOp2yC5FhlIQQqGr0PGIYNovWACJ+i6NBLxTQ4GO/3K 0XE5mA6UQbvRTw1TtLfU0Cr8k0YCy75e9h0WkKEw2mV42TzI5TnHDLX25WLPYVGnTJrJtcq5VXI xIECx+hZmz9e8tGwD5YZc3XeKimYxNe6GFvym62+zTaHk6JWqxaPjbVpKJgD55LuJElB+mIFoNE Qn8kycQAfeNh0J9s+SRBBEX86Vje/om1qK8AM= X-Google-Smtp-Source: AGHT+IFoWXTWe8jlxRjxHvZPZblyO9Cr/YskUX5eYeT3ub3lZX0WK4czrnFYRJEf8xU5Jy2Q5irSKg== X-Received: by 2002:a05:6000:2910:b0:3b7:99a8:bf6e with SMTP id ffacd0b85a97d-3b8d94c9fe1mr5005737f8f.51.1754233826203; Sun, 03 Aug 2025 08:10:26 -0700 (PDT) Received: from pro2 (p200300e0b70e8b002124748d09eedd4d.dip0.t-ipconnect.de. [2003:e0:b70e:8b00:2124:748d:9ee:dd4d]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-458953cfcadsm183507365e9.18.2025.08.03.08.10.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Aug 2025 08:10:25 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Pip Cet Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV In-Reply-To: <87bjowa1w0.fsf@protonmail.com> References: <878qk5qvob.fsf@telefonica.net> <86ikj9ueqj.fsf@gnu.org> <87tt2spv7t.fsf@telefonica.net> <87v7n4a5sf.fsf@protonmail.com> <87y0s0wjhk.fsf@telefonica.net> <87bjowa1w0.fsf@protonmail.com> Date: Sun, 03 Aug 2025 17:10:25 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79131 Cc: =?utf-8?Q?=C3=93scar?= Fuentes , Eli Zaretskii , 79131@debbugs.gnu.org, Yuan Fu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 03 11:35:55 2025 Received: (at 79131) by debbugs.gnu.org; 3 Aug 2025 15:35:55 +0000 Received: from localhost ([127.0.0.1]:45235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uiakc-0007bp-Dy for submit@debbugs.gnu.org; Sun, 03 Aug 2025 11:35:54 -0400 Received: from mail.eclipso.de ([217.69.254.104]:44886) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uiakW-0007bI-Ko for 79131@debbugs.gnu.org; Sun, 03 Aug 2025 11:35:50 -0400 X-ESMTP-Authenticated-User: 000D6BEA From: =?utf-8?Q?=C3=93scar_Fuentes?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclipso.de; s=mail; t=1754235342; bh=+T6nIRnpq18Nt+zXhy+rCqBQNCLgXTHqO6TVvtHeRUY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=P5+b941tw4eGVd1H8z6ubCQb80TR63VKGxoJFGudKEKfzjdFv9cR7lBUM6NzQ4EA9 E7or41CWzCs+SJwvKsWc6MsX/BafFl36w99JsmtCnsLzUmLJZuY4ANhaKkO0DvreiS z4+P+VsQAzq0pLLnqYuXMiG50DXVmFYYPbmQlf8NlZXeEr7CeQS98ygO6glqg7EHri cO9/OZUfQlZhP9EXNj10gNsemDwG1fZckCjhnGQdVyhIlyUGX58zdbFEzP/nRkn+0P pWukGKOXjK+JwYHHnuN2qD6cv9UufKKSIsTROtGFz/NvyrfZaz7R6AyYZNTry6t8lW dXByfx3gXJ1MQ== To: Pip Cet Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV In-Reply-To: <87bjowa1w0.fsf@protonmail.com> References: <878qk5qvob.fsf@telefonica.net> <86ikj9ueqj.fsf@gnu.org> <87tt2spv7t.fsf@telefonica.net> <87v7n4a5sf.fsf@protonmail.com> <87y0s0wjhk.fsf@telefonica.net> <87bjowa1w0.fsf@protonmail.com> Date: Sun, 03 Aug 2025 17:35:40 +0200 Message-ID: <87tt2owh83.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79131 Cc: gerd.moellmann@gmail.com, Eli Zaretskii , 79131@debbugs.gnu.org, Yuan Fu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Pip Cet 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 03 11:47:58 2025 Received: (at 79131) by debbugs.gnu.org; 3 Aug 2025 15:47:58 +0000 Received: from localhost ([127.0.0.1]:45271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uiawI-0008Gh-Dg for submit@debbugs.gnu.org; Sun, 03 Aug 2025 11:47:58 -0400 Received: from mail-24416.protonmail.ch ([109.224.244.16]:17867) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uiawG-0008GN-BX for 79131@debbugs.gnu.org; Sun, 03 Aug 2025 11:47:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1754236069; x=1754495269; bh=oNKABHrCIbjrwOSwLUgEG6mQgJBUb+uoO2UxEGyLLLw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=aB8e3kCDm23IWVUwUGFQ9Sz4NduoMjhrQqCCCasb/+5juHb6XJollu0QTYNt7XDaY 6yxUo8/nW+d05nuZqha6RlaD9SaObT4UoB00QxTL9cclCsvdvefl7tl2WBz6Albcne 14V/x764+q0lAS13EjxswjoBvgpZjMLoFY+ti7iW9sA4lO82nkrVbVNhXT+j+h2xYD 72bOBqpdksP5+fZruiGEPTVseIK8U1LTNqMptsrY342LokBp0uGdPeOzdWqT1oT8Io lKO8YlkgRaYAdlBk09rJjd/Sj6l1qR0tT5opNSstdVJUrKOxyVXcBnkgh6wnOXeVVq uRJkCjrjR1eDQ== Date: Sun, 03 Aug 2025 15:47:43 +0000 To: =?utf-8?Q?Gerd_M=C3=B6llmann?= From: Pip Cet Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Message-ID: <875xf49zm3.fsf@protonmail.com> In-Reply-To: References: <878qk5qvob.fsf@telefonica.net> <86ikj9ueqj.fsf@gnu.org> <87tt2spv7t.fsf@telefonica.net> <87v7n4a5sf.fsf@protonmail.com> <87y0s0wjhk.fsf@telefonica.net> <87bjowa1w0.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 91aec33b74cfe9ed8ad3a6f2ad97147f435302d0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.0 (-) X-Debbugs-Envelope-To: 79131 Cc: =?utf-8?Q?=C3=93scar_Fuentes?= , Eli Zaretskii , 79131@debbugs.gnu.org, Yuan Fu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.0 (--) Gerd M=C3=B6llmann writes: > Pip Cet 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 From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 03 12:02:17 2025 Received: (at 79131) by debbugs.gnu.org; 3 Aug 2025 16:02:17 +0000 Received: from localhost ([127.0.0.1]:45304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uibA9-0000hw-FK for submit@debbugs.gnu.org; Sun, 03 Aug 2025 12:02:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36824) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uibA5-0000hW-B8 for 79131@debbugs.gnu.org; Sun, 03 Aug 2025 12:02:16 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uib9y-0004nr-EY; Sun, 03 Aug 2025 12:02:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Bvl/G0FdI+CdmsMVldQJq2EvdFEzlaWABOToKxmB8xc=; b=LA/z5JKPhljOQ7OQSEbs 7jI4OJ50t6ylcadIZRjDTRjrtq3lmAmbnBSxgL+4b9s1XolT8ZMeAOLWJKy+ichpxLf9gT+3Y88zV UnU/TYYMPcjHZaZclh5+3WpRtEDs9gxPP2wGQeL0FyYIoubK9VGZWiKZamHcBQ8KXElVcd9nvAg4R wS/2nzGpeMXP8RFt3l0J8PESVWQa55GVNeHqF1NkvJNwwQXLjYGHA+a7iRzuj/iSQKew23TB8Mi8R sG5XZWHM9OGDa3xQBsaoDH0ftKAi3Gx3Ia1WLjSPioMlgXBJNbpLU0gh+gYOicuB65NOXFBAkCnj2 y3NgekZXwREbBQ==; Date: Sun, 03 Aug 2025 19:01:24 +0300 Message-Id: <865xf4xuln.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <875xf49zm3.fsf@protonmail.com> (message from Pip Cet on Sun, 03 Aug 2025 15:47:43 +0000) Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV References: <878qk5qvob.fsf@telefonica.net> <86ikj9ueqj.fsf@gnu.org> <87tt2spv7t.fsf@telefonica.net> <87v7n4a5sf.fsf@protonmail.com> <87y0s0wjhk.fsf@telefonica.net> <87bjowa1w0.fsf@protonmail.com> <875xf49zm3.fsf@protonmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79131 Cc: gerd.moellmann@gmail.com, oscarfv@eclipso.eu, casouri@gmail.com, 79131@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 03 Aug 2025 15:47:43 +0000 > From: Pip Cet > Cc: Óscar Fuentes , Eli Zaretskii , Yuan Fu , 79131@debbugs.gnu.org > > Gerd Möllmann writes: > > > Pip Cet 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? From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 03 12:17:28 2025 Received: (at 79131) by debbugs.gnu.org; 3 Aug 2025 16:17:29 +0000 Received: from localhost ([127.0.0.1]:45354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uibOq-0001Yt-Gr for submit@debbugs.gnu.org; Sun, 03 Aug 2025 12:17:28 -0400 Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]:59827) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uibOn-0001YU-IZ for 79131@debbugs.gnu.org; Sun, 03 Aug 2025 12:17:27 -0400 Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-458b8a63233so7460245e9.3 for <79131@debbugs.gnu.org>; Sun, 03 Aug 2025 09:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754237839; x=1754842639; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=DMBBH8CCSy/K16sVn3/REqAYByONQ/flBW9o32yXZ24=; b=f6ZLgR8vt45lgq10jxpqb97gZhBXD94vYSwav7S4lqkCAXGgXnoKSo5gi9hE72hQr9 CuiVUmfLYJIU96t0pf0tFv7UsJDWFKuR5/em83IQRV/sDu6/lw4Rhf6nXfodDwtlazb7 cZhM6sAYx4HAtIxhjsA5JnH6CtFA//TXV/lEkRmGgh3XuNKPAyN5rNDlGHVLD8sF+syH e7ijovvjX3Y7w2XLyJm0E+H2UpCCsStVxJqN2jFQILJdPcblqJNHHEbi2Y6UOa5HUcde Jk62RgZXP1thcYHVx2j3TA9MzjIPXdamkZc6Yly7tTfX3W6rXNBVrkWBaeFC5LSK45vD yL1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754237839; x=1754842639; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=DMBBH8CCSy/K16sVn3/REqAYByONQ/flBW9o32yXZ24=; b=KMWRKrvlotK2daoB9O8TL1l9MzTOMR1ArLWdCli/8rxZZlkJ6d2jFcEVC/piB5GpMq njSibnAWclW5QLwvFcGK8yvHx0NQ92S04iRY0igTyLKNbee1z1kz/5FJ/16IMNHNjU0q iK8ybPfY2R4jGY0RqyjW+GBk9xOm9kWohm0JymxsR0jZOTb0N1p3u9jwVT875y5LmmvS eTl6g3sRnl2pYoZT8t1desPtBkBn99oEzjA1uRzZCYpw8qFOzyqaan0dhI0CSieATqH4 t0CVdJKonQJBKyrW9NOE3HH6Js1A9ZPlXLcOEzZndiNoo+NTYxOeg5koU8BFzj9bjC3F MsgA== X-Forwarded-Encrypted: i=1; AJvYcCXFfy5XOhcKDaS7PuTqpPunHUhnA5F+jdAPpeAVXLDEh/9IdgpgizbyZL6J04W40MYGA8C34Q==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxL451IfzvTHQjPgBeHyPr6H4NaTml9C2hR5K2JtniUDMRLzU6H nM+27b244rhyI2e4m1jcxvSZjUllhPJKFOHwtgymyG12QTUZmxrN6n6R1I1hqgmz X-Gm-Gg: ASbGnctParjCAyg8lHVkvFMvgdT3Vs8ys+RqVpfCLGw5G2KQr+K7efjB4un1xLhbCd/ AmKu5hDPiYmU/0KsNw/wOtpZPB/INdz3GTztz8XFAhOf6XfOTN0Wenm7DF1nvXohey9MSbIEfIT PryEBPs1HDz0cy1RlEsD3qnyJbOV6Ai8k7USFNd+siOb8SJEWSafBWZ9hO6T+eDB+GbaouJ9QS6 Z4JowH+cN2YuHqby5aaI9Xk40ABnah1T5flEPyBO0AVO5SekUq58uboXDhinTMdZ4EEI1eWEmpA 8CydgilLn8H7FpNi7P9ykhghFYUko1EC2zL1QurEtuzyxhvMP4DDiNxMgossNc1JLwPmixanCkm UvLQrhUBJCYlVmGA8cPtq4CkKYaeSpT/345+1Im9zIz6S8sThvuz4pZRP7MWmHh2XFxWnnCYhaV POg5+r5WlKOR7DsPU2aF19qQo1 X-Google-Smtp-Source: AGHT+IE0cymxMWZbR7iiwI9a+oq5ILzEwBq3wXgsjfl+bD/hn7AUP9AFtYDASuyPalu6QT3JK7tFRg== X-Received: by 2002:a05:600c:4f88:b0:450:d30e:ff96 with SMTP id 5b1f17b1804b1-458b68742c6mr56811215e9.0.1754237839044; Sun, 03 Aug 2025 09:17:19 -0700 (PDT) Received: from pro2 (p200300e0b70e8b002124748d09eedd4d.dip0.t-ipconnect.de. [2003:e0:b70e:8b00:2124:748d:9ee:dd4d]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-458953eb7acsm173615415e9.28.2025.08.03.09.17.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Aug 2025 09:17:18 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV In-Reply-To: <865xf4xuln.fsf@gnu.org> References: <878qk5qvob.fsf@telefonica.net> <86ikj9ueqj.fsf@gnu.org> <87tt2spv7t.fsf@telefonica.net> <87v7n4a5sf.fsf@protonmail.com> <87y0s0wjhk.fsf@telefonica.net> <87bjowa1w0.fsf@protonmail.com> <875xf49zm3.fsf@protonmail.com> <865xf4xuln.fsf@gnu.org> Date: Sun, 03 Aug 2025 18:17:17 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79131 Cc: oscarfv@eclipso.eu, Pip Cet , 79131@debbugs.gnu.org, casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> Date: Sun, 03 Aug 2025 15:47:43 +0000 >> From: Pip Cet >> Cc: =C3=93scar Fuentes , Eli Zaretskii , Yuan Fu , 79131@debbugs.gnu.org >>=20 >> Gerd M=C3=B6llmann writes: >>=20 >> > Pip Cet 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. >>=20 >> 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? From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 03 15:01:15 2025 Received: (at 79131) by debbugs.gnu.org; 3 Aug 2025 19:01:16 +0000 Received: from localhost ([127.0.0.1]:45761 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uidxL-0002qo-Ku for submit@debbugs.gnu.org; Sun, 03 Aug 2025 15:01:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43134) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uidxG-0002qF-18 for 79131@debbugs.gnu.org; Sun, 03 Aug 2025 15:01:13 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uidx9-00079j-5K; Sun, 03 Aug 2025 15:01:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=hueQDUdhKrYaLnMOuBTx4PnnO/jurLE+Ns/catcbx00=; b=KUi11xVqSOLyjShBDYLq Jhl7uu4rph0rV4ODGQzy/7A247FNFD8HtK+dZJ9Kn5czkjtozuhwjy8NJDyxDK5xZVpYFQ4vqBIsc 1L9tNd9YAP85qD/4Rou5QYBBSP7LJ1wHa8q0oaimy6oC3bX0Xg0Z8026NdVBqVuycor67PU7RU6US gqmY7k8SyFJkVhHQ6xkVzEIDyoEGOrW5kWzdoHhoxlugKkvFhnhPjzZ1X4t2FESFXE8WV0D9hIOUi wdLgUKqrhgnAYWJxp6gmZhGVRiOPM12yMuH7QVZHoGQE7gvex0kouwUWYUHFjrDyXNxCE5uRmHHya 806LzPMZORLp7g==; Date: Sun, 03 Aug 2025 22:00:56 +0300 Message-Id: <8634a8xmaf.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Sun, 03 Aug 2025 18:17:17 +0200) Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV References: <878qk5qvob.fsf@telefonica.net> <86ikj9ueqj.fsf@gnu.org> <87tt2spv7t.fsf@telefonica.net> <87v7n4a5sf.fsf@protonmail.com> <87y0s0wjhk.fsf@telefonica.net> <87bjowa1w0.fsf@protonmail.com> <875xf49zm3.fsf@protonmail.com> <865xf4xuln.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79131 Cc: oscarfv@eclipso.eu, pipcet@protonmail.com, 79131@debbugs.gnu.org, casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: Pip Cet , oscarfv@eclipso.eu, > casouri@gmail.com, 79131@debbugs.gnu.org > Date: Sun, 03 Aug 2025 18:17:17 +0200 > > Eli Zaretskii writes: > > >> Date: Sun, 03 Aug 2025 15:47:43 +0000 > >> From: Pip Cet > >> Cc: Óscar Fuentes , Eli Zaretskii , Yuan Fu , 79131@debbugs.gnu.org > >> > >> Gerd Möllmann writes: > >> > >> > Pip Cet 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 07 13:58:35 2025 Received: (at 79131) by debbugs.gnu.org; 7 Aug 2025 17:58:35 +0000 Received: from localhost ([127.0.0.1]:35831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uk4ss-0004SD-Vm for submit@debbugs.gnu.org; Thu, 07 Aug 2025 13:58:35 -0400 Received: from mail-4322.protonmail.ch ([185.70.43.22]:12333) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uk4sq-0004S0-Ci for 79131@debbugs.gnu.org; Thu, 07 Aug 2025 13:58:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1754589505; x=1754848705; bh=yFrc2ZYcbQVwQaGFbPOzmHDbMxabD27DWqHLjerJhvw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=m18+CezjyreoaLD8snWGibsepIgKlEgEykvtATMAQlWVVuke8hDy93iobE9xr5s3F qx32L3tMp+tK+uGoxB/OV6lpJ3zD1TlVjtUPBSs+mpHAC48Ua27pcCb6/bJjH87X8e S76d8LvC1gaI1+y8ibfp9jHUr4caEkor4FiezNvRr2fc0U2fjN04dko5v6IpaV3Esg MbTrD+/rdjAoUWdynZpryzbt/YKYT8w3nrgfCP2afk9QNGXbnPaeVJikbvU3Julqxn zoCdPWn2h98f+kY6h8N/gXXcZslBO/0vdaQHBU9w7n1S4/LU5tF6z1lJqcASsDk8gQ NycMfEw0RT2hQ== Date: Thu, 07 Aug 2025 17:58:22 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Message-ID: <877bzf816c.fsf@protonmail.com> In-Reply-To: <8634a8xmaf.fsf@gnu.org> References: <878qk5qvob.fsf@telefonica.net> <87v7n4a5sf.fsf@protonmail.com> <87y0s0wjhk.fsf@telefonica.net> <87bjowa1w0.fsf@protonmail.com> <875xf49zm3.fsf@protonmail.com> <865xf4xuln.fsf@gnu.org> <8634a8xmaf.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 302983776d049ce042d87ac3821581d2ef126d1c MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 79131 Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= , oscarfv@eclipso.eu, casouri@gmail.com, 79131@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Eli Zaretskii" writes: >> From: Gerd M=C3=B6llmann >> Cc: Pip Cet , oscarfv@eclipso.eu, >> casouri@gmail.com, 79131@debbugs.gnu.org >> Date: Sun, 03 Aug 2025 18:17:17 +0200 >> >> Eli Zaretskii writes: >> >> >> Date: Sun, 03 Aug 2025 15:47:43 +0000 >> >> From: Pip Cet >> >> Cc: =C3=93scar Fuentes , Eli Zaretskii , Yuan Fu , 79131@debbugs.gnu.org >> >> >> >> Gerd M=C3=B6llmann writes: >> >> >> >> > Pip Cet 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 q= uit >> >> (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 From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 07 14:48:36 2025 Received: (at 79131) by debbugs.gnu.org; 7 Aug 2025 18:48:36 +0000 Received: from localhost ([127.0.0.1]:35953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uk5fH-0006sY-Re for submit@debbugs.gnu.org; Thu, 07 Aug 2025 14:48:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34170) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uk5fF-0006sL-KA for 79131@debbugs.gnu.org; Thu, 07 Aug 2025 14:48:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uk5f9-0007lP-AH; Thu, 07 Aug 2025 14:48:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=vN6ZdLnikydTKu7oj43cu9oH9HcSj3IdPFe7wcsPhek=; b=T0a/CG8b0s1mzJs3gZ0E p/u8xEP7OzzDPZRhH+TtgUvSnxMScmeV4nbHBpgk2+8qLmwLLCBSOqpFTJ+xXGmZU6G8un5ZLcsUY 1Lgfjt4lZRFjed9PeVBqrTD5rMJuk6a+j/f+rI1RnpGWR+c0ocmDbtjUU/7DycrgP40dPUYHn/XvP BURWcdVFls8DbnQHbQfEURD0JN+QZOdgv1UGDye/yp3vLUF+6pLETU/hhX6wb61JL+MkF7RCf8v9K sYS8J4GN7sTI4YvlMDQrcaB00p7kRwqZ78ID6KOpLDBuLEWjzuLCoJPQsOt04b/Ex1txOIrrEzpMH CTCmu1LGwdgL6A==; Date: Thu, 07 Aug 2025 21:48:24 +0300 Message-Id: <864iujotmv.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <877bzf816c.fsf@protonmail.com> (message from Pip Cet on Thu, 07 Aug 2025 17:58:22 +0000) Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV References: <878qk5qvob.fsf@telefonica.net> <87v7n4a5sf.fsf@protonmail.com> <87y0s0wjhk.fsf@telefonica.net> <87bjowa1w0.fsf@protonmail.com> <875xf49zm3.fsf@protonmail.com> <865xf4xuln.fsf@gnu.org> <8634a8xmaf.fsf@gnu.org> <877bzf816c.fsf@protonmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79131 Cc: gerd.moellmann@gmail.com, oscarfv@eclipso.eu, casouri@gmail.com, 79131@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 07 Aug 2025 17:58:22 +0000 > From: Pip Cet > Cc: Gerd Möllmann , oscarfv@eclipso.eu, casouri@gmail.com, 79131@debbugs.gnu.org > > "Eli Zaretskii" 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? From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 08 00:37:28 2025 Received: (at 79131) by debbugs.gnu.org; 8 Aug 2025 04:37:28 +0000 Received: from localhost ([127.0.0.1]:36635 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ukEr6-0008UW-Eq for submit@debbugs.gnu.org; Fri, 08 Aug 2025 00:37:28 -0400 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:44358) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ukEr1-0008UF-Pg for 79131@debbugs.gnu.org; Fri, 08 Aug 2025 00:37:21 -0400 Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-451d41e1ad1so10966405e9.1 for <79131@debbugs.gnu.org>; Thu, 07 Aug 2025 21:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754627833; x=1755232633; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=DvHO+G0Yc9Jh+lvCRpl+Zsv42ngnSZnTAJRyGHaqQl4=; b=BzmWn3ZOmhFmX2PyOVYEMJBQ871Aoz5RPqCs8+uCK6Zzbw2Tt1O82zVglAqiPzdy+T x9Cl95JCf1BE9IxnmRedKdrX1sG/5iuXanq+ZCc2f0bG2wo2lWMiIH0Iwkw2GIDGtnwa synyTdqtaQv2SxCExuqjoLohqA79VS8HQ0i8ZV8lfe9webCvl+gnHupIPmvqe4Mvjjyo xQrNYZMNgGlfiKQRwMaNW83bH7iMbD8cAf6vcrvorHKaC85XAjwCXVS2zhDEHSv1jIZs GD5T6CEGsu0oGqIh2yZLtkx0QPpwVNq9emV1zCe/pg9UODPmYmumW4uoBHfZK12jd27b mvQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754627833; x=1755232633; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=DvHO+G0Yc9Jh+lvCRpl+Zsv42ngnSZnTAJRyGHaqQl4=; b=cANuYudrpL7k/pELm5z/R3ISm7eY6V2eOULpDdVzO/pr8wq5rPemfLvd6x5oog5i+Y APX6xBe9bueMRwVMIg57b98PHI1zk2YzGcGlVQ8pqnlyDLQQKoxfuqpFnjqXNd35sUcy KBMMy7eUsk3Hy31SDIWkhM8SGjD10EjLkYJ+jbBlVYUz8HpCR1LB6rJ/N794fUrttxSZ nG5jbiMUQN0kXx45mRX8ZMMVRcKDCWeURAZLEUlbDdL2QLdG2urWMkkrW9Nw8lo9m/HU YhY5Zwl+mguVOJjbHKUL592PEWQABIqXrGh3L/STx4AE8QCqmMTqFaB3cHpEAYPjwgF6 bvNQ== X-Forwarded-Encrypted: i=1; AJvYcCWSTxRpbO2J91xmrFz1If1jDyodb8UQ5DjwNzkaKWU2m6Xcpd9EXPkZsmU9e6tvabc7UhBkAg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzPEr4kjigBn8Z7Hufg6D0yKKMilCQFYqTJrI7So5WhxtVrMutT calaDLpC2k2rSfDTxIBDIChE0ew627KDuNQvk5ORX2o+6mBrAodQtRngpzKyjA== X-Gm-Gg: ASbGncvT3Ng1ZAhebg1kckeMIVPB/C5/lEL4fJawg8T9uYLAUy+ri3wJS9lbOBe3l8b TFkgB2xL9bruWgaz64WJdyW+TpYZ7CyHqD+BUPPdOjnxolyjyZNp51jb93PBchVvd8+E9nFWNyH 09BPM0URaS1v0tFDlfCK9faC5cTr0x6KBBPKNjTKVJravoRcRNVLZc71pM5v6B1WYyml519Jfof 21AxNCgVoX9AZ40KTn2raK247i9mt8bxF9KVgxaQ4LOwvbcBvse0RpZrbnAyInpwD9PKf32xc7j F2WOkCUeukHLJAVXxzGAUoSbuUVNcA9LzT5dxH7flfvDngd/Je54nurNQh99ANKNwrMGmWOOyD9 amDbfwcxDpoSCLJws9BMGLYY8nGgZIQHBLCzAtr8hBQu0sFhJ5FQJFUogjV/nMFMVTlvNGsdArJ YoFYP4EogbK56y4jRg9SgJUaQcoqn5FIU= X-Google-Smtp-Source: AGHT+IGs17mKP02AeO+BcYLSFkam1VNrJ2EKHVb2nUYgLTCu3Z9TqwW+58TvbQiguCtCaQ/aK8IpkQ== X-Received: by 2002:a05:600c:474f:b0:456:1d61:b0f2 with SMTP id 5b1f17b1804b1-459f4fc32fbmr10772765e9.30.1754627832974; Thu, 07 Aug 2025 21:37:12 -0700 (PDT) Received: from pro2 (p200300e0b741ff00c4d7f6fa22926ac6.dip0.t-ipconnect.de. [2003:e0:b741:ff00:c4d7:f6fa:2292:6ac6]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3b79c470102sm28690113f8f.53.2025.08.07.21.37.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Aug 2025 21:37:12 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV In-Reply-To: <864iujotmv.fsf@gnu.org> References: <878qk5qvob.fsf@telefonica.net> <87v7n4a5sf.fsf@protonmail.com> <87y0s0wjhk.fsf@telefonica.net> <87bjowa1w0.fsf@protonmail.com> <875xf49zm3.fsf@protonmail.com> <865xf4xuln.fsf@gnu.org> <8634a8xmaf.fsf@gnu.org> <877bzf816c.fsf@protonmail.com> <864iujotmv.fsf@gnu.org> Date: Fri, 08 Aug 2025 06:37:11 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 79131 Cc: oscarfv@eclipso.eu, Pip Cet , 79131@debbugs.gnu.org, casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> Date: Thu, 07 Aug 2025 17:58:22 +0000 >> From: Pip Cet >> Cc: Gerd M=C3=B6llmann , oscarfv@eclipso.eu, >> casouri@gmail.com, 79131@debbugs.gnu.org >>=20 >> "Eli Zaretskii" writes: >>=20 >> >> >> Unfortunately, while Fmemq and Fassq are easy to fix, Fget can als= o 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)? Otherwi= se, >> >> >> >> You mean inhibit-quit? >> > >> > No, I mean prevent MPS from interrupting a given short sequence of >> > code with GC. >>=20 >> 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 08 01:43:42 2025 Received: (at 79131) by debbugs.gnu.org; 8 Aug 2025 05:43:42 +0000 Received: from localhost ([127.0.0.1]:36745 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ukFtG-0003Kc-5Z for submit@debbugs.gnu.org; Fri, 08 Aug 2025 01:43:42 -0400 Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]:49567) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ukFtD-0003KN-Ov for 79131@debbugs.gnu.org; Fri, 08 Aug 2025 01:43:40 -0400 Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-458b885d6eeso10523915e9.3 for <79131@debbugs.gnu.org>; Thu, 07 Aug 2025 22:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754631813; x=1755236613; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=blicOy8PmFy8mOHXioiCX+YUKIxuewjv/iYcd9Ggfs0=; b=Qw0Q2sr05kquz0YXmiTqiHybBWld3/gJ6m9/i5HbX7FzE/VuEN9R9Sb8+oiu37YrYu t1uh3q4AL5idn/TpcOsrXTgtKLUEr39wL/onY+fz6IXpq30gnfCkH4RobxlB/UeHLUaC 84yqQpRGmI4abB4z2nhbBUtP2HYhfNzLMTKfwW52RYoaQsQgPecnWjOQnn31N1ovMfEX yWSGumbP0pK/34jRndS7amFFV+6aQ/4z0EVbF8rRYCzXJAfajXz2dt7Cr/nrmufUMwiv kKFyrgGyY3OVAAZIgKIsiHKiG5lF5VS1J37i5TGiYixYeOfyiohPSz2ih4Twl3EmBslq 5jrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754631813; x=1755236613; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=blicOy8PmFy8mOHXioiCX+YUKIxuewjv/iYcd9Ggfs0=; b=G6ZssXs+EzcFOvTkQuKqo6gNTM6HE+wb4bId4sQD2Wu/cregkz3DeZos1pzkX2+pEU c/FVMDusLJtKdOsgpUC9P0lKd4SmQnV82ZH32LWIRkz+jnPky0qlggfmX+39ismnlCfp 8rvzKo18V5LYEM/G2I0IJ9KqR5Sep48NTHySKJsffTema7lUoRQf2KTqJNJvhvnrHOr5 bty/s7qHUFbyHy0QLBVblU7ngRCY1svWIVmJfHaKDswGut18GltVeEx1hgvL5uWI+NHH XmViBHaUKaYwaOvq1QI4Tnq2JJwKeFL/G/gXXeHUnd3yAueQDh7AkuVLXdqh1CsLLxO8 rCpQ== X-Forwarded-Encrypted: i=1; AJvYcCUMHTIzx9C1Bnw/ni3d1g8dfBTL/betHk9M5P6v991Zd4MuD7cwPYanTdk6P/Pn8K+ZPN2nAA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxpsyBU+dPKHcg1GPwU4hIFLqw5HXQ6r6vKG/JnOLolE/KaoXVZ jKBrMNJI2DFKBNKhCAm7IsGS7BXYxZPJ/5s8h5V2i57Z0d5MfnzorpLtai3JpQ== X-Gm-Gg: ASbGncscKUZkD4aESxMoj2I8ep8115Rt4gX8XT0DJoGuVsRe1GFWmwvFZJXhMvjv7Pq bV7QnjYg+LXbrHLjLm7xzrpd4Rz0BP0e5/Ac9AiVcPCDpRIzwuEQGatxYQ6pXyM4JDFRUrYNtjQ 2e5yInujLZX6iawz9RmCJHfxLZ0tB3BCcBW2Il/dj5W8ZL7CBpzUkNeMksB5KEzVqIjZt4ar3uu 9QEUva5ox80vHqotxJzXgubnkXchfqJW/Qp0ASVi8zuH5khmZhqsEZkDO0PxmOqNCJEF1H8pgbU 0S9raL6ZnxSrovif8ugIfiGClIyn3id7TszUGyQiowh3f5hF9rLivd24kO/meFDnPOJYo0mDBtO bX8cqdB+FzGUZw8CZBAIBvUzCCRr0nVye8p/pzly1sOhNPnTjW9PCBMXjrtqs++Dk06zI127p+H ilFMP2EY+Ojk0sOc2LR+kh50xwF1Z53pHdjP0cLI6gig== X-Google-Smtp-Source: AGHT+IFW464T1g9z/26pNmpo18fZNz/DBAtd9LrJ2ok093UlH+SibSD2UlFZ2j2xNcUoFtRtXGBlog== X-Received: by 2002:a05:600c:1912:b0:442:c993:6f94 with SMTP id 5b1f17b1804b1-459f4eb1a07mr11661295e9.12.1754631812911; Thu, 07 Aug 2025 22:43:32 -0700 (PDT) Received: from pro2 (p200300e0b741ff00c4d7f6fa22926ac6.dip0.t-ipconnect.de. [2003:e0:b741:ff00:c4d7:f6fa:2292:6ac6]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-459e586eef8sm117827455e9.21.2025.08.07.22.43.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Aug 2025 22:43:32 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV In-Reply-To: References: <878qk5qvob.fsf@telefonica.net> <87v7n4a5sf.fsf@protonmail.com> <87y0s0wjhk.fsf@telefonica.net> <87bjowa1w0.fsf@protonmail.com> <875xf49zm3.fsf@protonmail.com> <865xf4xuln.fsf@gnu.org> <8634a8xmaf.fsf@gnu.org> <877bzf816c.fsf@protonmail.com> <864iujotmv.fsf@gnu.org> Date: Fri, 08 Aug 2025 07:43:31 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 79131 Cc: oscarfv@eclipso.eu, Pip Cet , 79131@debbugs.gnu.org, casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Eli Zaretskii writes: > >>> Date: Thu, 07 Aug 2025 17:58:22 +0000 >>> From: Pip Cet >>> Cc: Gerd M=C3=B6llmann , oscarfv@eclipso.eu, >>> casouri@gmail.com, 79131@debbugs.gnu.org >>>=20 >>> "Eli Zaretskii" writes: >>>=20 >>> >> >> Unfortunately, while Fmemq and Fassq are easy to fix, Fget can al= so 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)? Otherw= ise, >>> >> >>> >> You mean inhibit-quit? >>> > >>> > No, I mean prevent MPS from interrupting a given short sequence of >>> > code with GC. >>>=20 >>> 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 08 02:19:05 2025 Received: (at 79131) by debbugs.gnu.org; 8 Aug 2025 06:19:05 +0000 Received: from localhost ([127.0.0.1]:36798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ukGRU-0004yC-Io for submit@debbugs.gnu.org; Fri, 08 Aug 2025 02:19:04 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41428) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ukGRP-0004xa-5e for 79131@debbugs.gnu.org; Fri, 08 Aug 2025 02:19:02 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ukGRH-00074o-R9; Fri, 08 Aug 2025 02:18:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=DnaULmlgVvb6Hcwd06JzOFCvF3RXFRJ65D+hT9bJ5p0=; b=I1S/9qVnubjOxBBwovbA VMTsX9hHlx/ejCY+RM4YDf/3TMHGvCKEMOn1z0EvwxpNC+j78+PQlhNyydHZkleB5Cu4fSrcCZBN1 7rqfC/DuWlTlF73FYUOeJBeZXSmMKzEYUx1j//CiUq5z6iylT5K0i6KSr6QSOVCGI/Mf4nVNBsv+X ED4V/6CX8BG7HxH5iG407mnXXwrU3nO2ADukn6yFIoQ9G4CepNw9oAOizlYcRkaZea4s864fu9fkE jOlSOTQaIu97MIH4R/Lpjb7DAbi5oCA0wXIzBzh4TKLrWt19ducPSrdC7+7e2r7R1Qse7LbaNaQ3E 4eSnnbqM1J8BiQ==; Date: Fri, 08 Aug 2025 09:18:48 +0300 Message-Id: <86tt2inxo7.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Fri, 08 Aug 2025 06:37:11 +0200) Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV References: <878qk5qvob.fsf@telefonica.net> <87v7n4a5sf.fsf@protonmail.com> <87y0s0wjhk.fsf@telefonica.net> <87bjowa1w0.fsf@protonmail.com> <875xf49zm3.fsf@protonmail.com> <865xf4xuln.fsf@gnu.org> <8634a8xmaf.fsf@gnu.org> <877bzf816c.fsf@protonmail.com> <864iujotmv.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79131 Cc: oscarfv@eclipso.eu, pipcet@protonmail.com, 79131@debbugs.gnu.org, casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: Pip Cet , oscarfv@eclipso.eu, > casouri@gmail.com, 79131@debbugs.gnu.org > Date: Fri, 08 Aug 2025 06:37:11 +0200 > > Eli Zaretskii writes: > > >> Date: Thu, 07 Aug 2025 17:58:22 +0000 > >> From: Pip Cet > >> Cc: Gerd Möllmann , oscarfv@eclipso.eu, > >> casouri@gmail.com, 79131@debbugs.gnu.org > >> > >> "Eli Zaretskii" 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 08 02:25:17 2025 Received: (at 79131) by debbugs.gnu.org; 8 Aug 2025 06:25:17 +0000 Received: from localhost ([127.0.0.1]:36815 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ukGXV-0005M4-EK for submit@debbugs.gnu.org; Fri, 08 Aug 2025 02:25:17 -0400 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]:56439) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ukGXQ-0005IG-BX for 79131@debbugs.gnu.org; Fri, 08 Aug 2025 02:25:15 -0400 Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-459ddada9b1so16306895e9.0 for <79131@debbugs.gnu.org>; Thu, 07 Aug 2025 23:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754634306; x=1755239106; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=BcT6eB3Epbwv3Wz0Iid6xj42lKPv75YPM7gqSQTK5aA=; b=aFHRKWxMS4yZX3wRs3jt7SYLZOnDqwl2aroQoCzodAYNED5cyMkK4hJ6WSgaz2J+nq 5aL+BBqCOtwKz2RVRUIJvEuN2eTQ0xefNrTMQwgWEV6qzwvrczYnUypEOsGAIEh+Nc5p ssLSInASSxwgl8GVLbrEjNfEOKTa0/5KFeSCuuQPjMLZP7lmCP8zRfcuJcBlvut53+QL 9hkyvFwXJ/6ONhGsApYEeC7wajKdBOxIW9PDzHyz1V2/uuqgeQSMM6foRf5e864PJGv9 UmYCqNXSuDw7fZBWJS+VEk9YmaZTiHjieGKbW9cVfpyZDw4xnKxhw2cn03CskxRfx+sb /yOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754634306; x=1755239106; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=BcT6eB3Epbwv3Wz0Iid6xj42lKPv75YPM7gqSQTK5aA=; b=xAx9iZ/cm4NfLuUR1ciIhgWtFrGsoALGfxMR5/0S1pRSfTJ305bZBKnKZl8UHrl+AT vCdNxJYFJyKV9BS5girdG7B4LnLtfwyYC0kzMrVgDVg2Jr8x2ioT/sFHIYFjExCJxKKX IhDFyegAa62FS/hV6mjTy20pWOv8e3rlUR68zW0GR2aYVZC8S3NPvyUJ9S9ULmiRKpxb 6UqY818XXypMWUL3VD3yXAcp/kXsPmtMqvZ6kXnShwpyXuXQmvTRDGasiUa9l+dm/vyE 3j5aN2OTim89FKjsJUd33OdngvTk0fmRiS1jRoBfemWEqx8od1BVeHUBlwJ/v3lpxli3 DUhg== X-Forwarded-Encrypted: i=1; AJvYcCXmsAaq1smTxaufI2tN8YQsB9LIC8X9UVSCvQYi3OotY+7mDRRH6YafAZswlXZNT19HSlGxuA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyjhEQI1lTveBc9wjAAh8l+9r9N9wKBjh5XAcLCxDgPv/iisEQ/ kXLRJG5dua7Ax4Y3z9SoMUris8Gd4StP23nwtH/EkaR7I+A4UZgGeccOtjHg3Q== X-Gm-Gg: ASbGncswVnK0zG0IkCdAaTWsr39bZal/ogU1AMjlqlrxe71N2SWsWhHbdrRaQTAUbPD wNWNGFwCAq9UwmuVoBfx0Dr8IsuHy6IgTcAyTepBfbF5tNi9HPMiExwezol4pV1HnzOUwjgnv7P r3KS+Wbi4alJ/uC6BVtt2jdPy3MhKjGp0IGPfkhm+HRzdC0dIeXx9AYZVMBSYnwkIHQPhbqwFWk jd0rspgSBRAg8D7XnQsZlUnZ8LrVLEQZIv4Ydm1j/pJjeJ1YL5y7IvzmcLmXtDuYO9LsDHk84JP URjFhYu2/m6U6ZW3G/ePZgg1DgTWrsX40y0JsN8tepzM1qlNeMuDIVJ6Am6PvsBknNns+iLc9O+ +CquGX5oV6B8N293LdXjucDhDQ0hSy59TyJf7wtuRfH8b9KRC2L5teyX2NqUqrbQ5VTA8zk/zp9 qhweZCcmYqzZmnJhF3e84WSdqb8XXroWE= X-Google-Smtp-Source: AGHT+IGp6f2oLnrI/9xlv1tLj21eFVCzgGYSr2JwUM43xHZPNePLUneYXUVacpoXd+bPSxMY2Xa/Pw== X-Received: by 2002:a05:600c:4708:b0:456:10a8:ff7 with SMTP id 5b1f17b1804b1-459f4f146dfmr11636125e9.28.1754634305609; Thu, 07 Aug 2025 23:25:05 -0700 (PDT) Received: from pro2 (p200300e0b741ff00c4d7f6fa22926ac6.dip0.t-ipconnect.de. [2003:e0:b741:ff00:c4d7:f6fa:2292:6ac6]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-459e5e99e04sm118205305e9.11.2025.08.07.23.25.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Aug 2025 23:25:05 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV In-Reply-To: <86tt2inxo7.fsf@gnu.org> References: <878qk5qvob.fsf@telefonica.net> <87v7n4a5sf.fsf@protonmail.com> <87y0s0wjhk.fsf@telefonica.net> <87bjowa1w0.fsf@protonmail.com> <875xf49zm3.fsf@protonmail.com> <865xf4xuln.fsf@gnu.org> <8634a8xmaf.fsf@gnu.org> <877bzf816c.fsf@protonmail.com> <864iujotmv.fsf@gnu.org> <86tt2inxo7.fsf@gnu.org> Date: Fri, 08 Aug 2025 08:25:04 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79131 Cc: oscarfv@eclipso.eu, pipcet@protonmail.com, 79131@debbugs.gnu.org, casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 08 03:04:52 2025 Received: (at 79131) by debbugs.gnu.org; 8 Aug 2025 07:04:52 +0000 Received: from localhost ([127.0.0.1]:36906 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ukH9n-0001bT-JH for submit@debbugs.gnu.org; Fri, 08 Aug 2025 03:04:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53398) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ukH9j-0001b0-6s for 79131@debbugs.gnu.org; Fri, 08 Aug 2025 03:04:49 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ukH9d-0005Qa-0t; Fri, 08 Aug 2025 03:04:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=2NG/UiDt/JA+wK0ki48jQTzpbHwA/8YY6+Nvey8+dZA=; b=bXevkeekFb93N0khJ9wZ PIRhgyMvda0l651Sn/Dz7LLupju/0T1/ZH/ldJxCFDpRzA+/PXeyHpkXLLHx+G3/itgJHpJKZvf4e 1lnBPEtRy3Q15Yc3anMe0HU03/RT+6qhIHFtVlJpkNYTEwcHXNiI/KsjsWigsVcBjd3aWxdpe+akf k8u+du6wUhvqh9H5vduUaAk2xVAYJKNDsLYuge2kFqEyFjh4nKuoBh3haZsFBOpRmL7Q2mcKIGnsk mnwQGGIF61TN1Cg0P7GIQ+hN6ukQmWyBVq7ddLFljVYN3YtrLLEtNgtiGoexHqcqKMsJVE0aa9FlF ReTdysMsT1GGHw==; Date: Fri, 08 Aug 2025 10:04:37 +0300 Message-Id: <86qzxmnvju.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?iso-8859-1?Q?M=F6llmann?= In-Reply-To: (message from Gerd =?iso-8859-1?Q?M=F6llmann?= on Fri, 08 Aug 2025 08:25:04 +0200) Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV References: <878qk5qvob.fsf@telefonica.net> <87v7n4a5sf.fsf@protonmail.com> <87y0s0wjhk.fsf@telefonica.net> <87bjowa1w0.fsf@protonmail.com> <875xf49zm3.fsf@protonmail.com> <865xf4xuln.fsf@gnu.org> <8634a8xmaf.fsf@gnu.org> <877bzf816c.fsf@protonmail.com> <864iujotmv.fsf@gnu.org> <86tt2inxo7.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79131 Cc: oscarfv@eclipso.eu, pipcet@protonmail.com, 79131@debbugs.gnu.org, casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: pipcet@protonmail.com, oscarfv@eclipso.eu, casouri@gmail.com, > 79131@debbugs.gnu.org > Date: Fri, 08 Aug 2025 08:25:04 +0200 > > Eli Zaretskii 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 08 03:10:23 2025 Received: (at 79131) by debbugs.gnu.org; 8 Aug 2025 07:10:23 +0000 Received: from localhost ([127.0.0.1]:36923 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ukHF5-0001uR-Hz for submit@debbugs.gnu.org; Fri, 08 Aug 2025 03:10:23 -0400 Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:46489) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ukHF1-0001ri-Ez for 79131@debbugs.gnu.org; Fri, 08 Aug 2025 03:10:16 -0400 Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-3b7910123a0so1565485f8f.1 for <79131@debbugs.gnu.org>; Fri, 08 Aug 2025 00:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754637009; x=1755241809; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=yKMydL/hj2diOaii1k5gv1O7uijP0g5BjJBbtejou5o=; b=nUsnrOlqRlWq7mylsBUA7ksTB+XvdH1SujQS4rmucSnqC0Y9z/oZp5x1C86E0codKU iJlu88xtPIFNxqadXY8y3P6fAF3M//R54VXWw6ijEKrK1vh9BzNOd8cy+RxShMLvk9BU nCoXYYgnVAp53SRo/4ZFrx1bKs2NDpIJ6lI5qAJN0q40Dy7KWXuWQMp/FWVxYqRBS6om bIhdn3JcMfw3TzXEHrawDzVtzB4RSRKN8PTL6MtDzW46p3YMb1rXC3PwQIFDCeIgeT6f LYtm4LiGW6l3KjwmOfh2YnIHpuQ3AntPXfBvOFbhMasomtCDOgwY0OBvTsfbIdJ91sYd qwoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754637009; x=1755241809; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=yKMydL/hj2diOaii1k5gv1O7uijP0g5BjJBbtejou5o=; b=lTZPegVO3ps3b8a0o5Bk6umkiNTXbPvgr6poo5iwuRSkuWm4BQ6VOBIE4K7lkf17dH wDa53K4852kzuy3rGZigN8W3c0vDIfU3/CdtPjnQx8jj9YyPAHgk/LoVvSXMbhs1hXbg HUU5/OLPx6FvvNOvn1aU2woAzbeUSvES3rKtk7RMj+fr+75DxZEUXb25MLFgMux+FDP5 9kiu3wUu0OudEnDz2gTt18fx69gSuZrI3cSFwvDsQ7WYgBJfR/Uo9cFnpyadfZGP31tK vOXJA6HEdNw9A3PsWwhODsL6RtXJ3qROjBtyKZhCV3SJpk+bQdF0kkqOTXkv95Y8UMTl lk8g== X-Forwarded-Encrypted: i=1; AJvYcCU/+0jPA+Qni1K2YjXpJ8TN79ADV7oqJJndNTeUXbhESeba5nrVn1NZyWP53ltO/4pTfjhdtw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YymcQ1kVvvkfuTW0wC1dAx1dj5B8eWQPo3fsepFgsxAfq1tSY8Q OttzrQoEtXRypT0ZJCtupTLeuSLQCbaxNR2ZVc91RqR79KNcGZAAbPgw6TUZpw== X-Gm-Gg: ASbGncuO/J9H1kGP1UFlvl5mFJd+rjbRkm79V+TWOunjdHHccrhEbvF/GFyM1EGoth0 06uGjx74n/kJHp4l+aXs1YrmwJ19TLIek9It2g7w1L4AX4IG1IRUCNIt8t8ZXR/Pvjd/AWMeBNc CObyVUtS3oYM6VxNsiAevNgHMKzPCRHS7bR5S9Qz2MrAhNbmuSWwMRIdubn4pcRs4dhNAWNMd0P NSSWo6e0LvEZuV/VBsCDm2Th1XKD3/82ynOTjqUbVmaHQoPmbYM0wdfzdbCWuFOMjgqTibg88Qb G25aViyWK3HyusNpghOgjCDHe9SQq5VAlAipQo1fzkem3Tpi6ALRa7z+ArK3eqFmRB1kSU9TMsi 86IW8GE5621eyaKqYhrh4tOP9beHo+E+l+rxRHxDr3NAliL6Wji4ru8Zy72QoYi8yPLCE6N5hyt VCmP4+CAqCwnIounMFGF32uO6iyN7egHk= X-Google-Smtp-Source: AGHT+IGTpc6d3nWLxN9NkvtoCBwTGRnpk/9445KWU7d3MKBHvRuHEVCppshry1BJ943GPwSH07/gag== X-Received: by 2002:a05:6000:2211:b0:3b7:5dda:d57 with SMTP id ffacd0b85a97d-3b900b8bcaemr1354586f8f.50.1754637008422; Fri, 08 Aug 2025 00:10:08 -0700 (PDT) Received: from pro2 (p200300e0b741ff00c4d7f6fa22926ac6.dip0.t-ipconnect.de. [2003:e0:b741:ff00:c4d7:f6fa:2292:6ac6]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-458953eb7acsm362629165e9.28.2025.08.08.00.10.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Aug 2025 00:10:07 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV In-Reply-To: <86qzxmnvju.fsf@gnu.org> References: <878qk5qvob.fsf@telefonica.net> <87v7n4a5sf.fsf@protonmail.com> <87y0s0wjhk.fsf@telefonica.net> <87bjowa1w0.fsf@protonmail.com> <875xf49zm3.fsf@protonmail.com> <865xf4xuln.fsf@gnu.org> <8634a8xmaf.fsf@gnu.org> <877bzf816c.fsf@protonmail.com> <864iujotmv.fsf@gnu.org> <86tt2inxo7.fsf@gnu.org> <86qzxmnvju.fsf@gnu.org> Date: Fri, 08 Aug 2025 09:10:07 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 79131 Cc: oscarfv@eclipso.eu, pipcet@protonmail.com, 79131@debbugs.gnu.org, casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: pipcet@protonmail.com, oscarfv@eclipso.eu, casouri@gmail.com, >> 79131@debbugs.gnu.org >> Date: Fri, 08 Aug 2025 08:25:04 +0200 >>=20 >> Eli Zaretskii writes: >>=20 >> >> 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?=20 >>=20 >> No. >>=20 >> > The discussion was about igc making this happen, or making it happen >> > more frequently. What you say seem to be unrelated. >>=20 >> 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 08 06:20:00 2025 Received: (at 79131) by debbugs.gnu.org; 8 Aug 2025 10:20:00 +0000 Received: from localhost ([127.0.0.1]:37298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ukKCe-0002QC-2c for submit@debbugs.gnu.org; Fri, 08 Aug 2025 06:20:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44830) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ukKCa-0002Pm-LH for 79131@debbugs.gnu.org; Fri, 08 Aug 2025 06:19:57 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ukKCT-00085T-Py; Fri, 08 Aug 2025 06:19:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=ezdiZ4qhrDAPBmU5a07EKufEKNs1/13VxKG6X6H7BQU=; b=GxinyxF4RKkm7I12QoKm m02HAZu+4/LfzhufxjvXpaa2CoPIy9r7JYGPycPJzGvXSP95X0kuZYQYlTU4Ts3hq7rV7f2VRQKI/ FpyhYAMN8nHZNqXyLU08gDDZhOslnSRfnCflri3MXmht8BsHAZcQg3RK155GPJGTntUuq2fenTpZA +1nqvadp8FtICFCBoRVjmTUJQqxjHmBj6QO8VPyoCH1un7kRx9gqPu4DbIXz6el0BuFpVtKeiKxfw ESjYDcx4EXhE4WoT6BPkMlLFV0mzhEWv+Wkup7Tp6o5t++RSgy06cqyQl6yY6E7PYOk1agwpbTuMJ EXGH5sGs2128qQ==; Date: Fri, 08 Aug 2025 13:19:46 +0300 Message-Id: <86o6sqnmil.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Fri, 08 Aug 2025 09:10:07 +0200) Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV References: <878qk5qvob.fsf@telefonica.net> <87v7n4a5sf.fsf@protonmail.com> <87y0s0wjhk.fsf@telefonica.net> <87bjowa1w0.fsf@protonmail.com> <875xf49zm3.fsf@protonmail.com> <865xf4xuln.fsf@gnu.org> <8634a8xmaf.fsf@gnu.org> <877bzf816c.fsf@protonmail.com> <864iujotmv.fsf@gnu.org> <86tt2inxo7.fsf@gnu.org> <86qzxmnvju.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79131 Cc: oscarfv@eclipso.eu, pipcet@protonmail.com, 79131@debbugs.gnu.org, casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: pipcet@protonmail.com, oscarfv@eclipso.eu, casouri@gmail.com, > 79131@debbugs.gnu.org > Date: Fri, 08 Aug 2025 09:10:07 +0200 > > Eli Zaretskii writes: > > >> From: Gerd Möllmann > >> Cc: pipcet@protonmail.com, oscarfv@eclipso.eu, casouri@gmail.com, > >> 79131@debbugs.gnu.org > >> Date: Fri, 08 Aug 2025 08:25:04 +0200 > >> > >> Eli Zaretskii 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 08 08:10:30 2025 Received: (at 79131) by debbugs.gnu.org; 8 Aug 2025 12:10:30 +0000 Received: from localhost ([127.0.0.1]:37545 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ukLvZ-0004kQ-WB for submit@debbugs.gnu.org; Fri, 08 Aug 2025 08:10:30 -0400 Received: from mail-10630.protonmail.ch ([79.135.106.30]:28771) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ukLvV-0004k7-C2 for 79131@debbugs.gnu.org; Fri, 08 Aug 2025 08:10:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1754655018; x=1754914218; bh=QOra4hJ0le5AZCJxsrCn2Oi62xVscNtIQ03dQCZni0A=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=HCIXjLnSghzxD9nJcH5/ZX58uADOoQYPxmm0HGFodQDd04UK7UWMD0nSNdHW9l2En Iu8QMA+bdHuemSLCELEH+WAwAzYHUWbSQreyeTLw5/v6/wk7U0EKG5t45ueJLpXB4X WOOOF28pub1BN2DeA62X1cb2kyPPO8RtmqT+gnh1iw/QYkoKWlHMiegi+HnPAIdW7t I++SMvfHLwatqgq7zmZWCmMzUFRrr3XcW6OTL56jroVyPwd/oDCYcFgCQhBldIFXX/ +s76SKg/2m7f4CzPZxa71Loa1xoqTE1TOYBsjk+LjC3WdKsvvbuSy8nx9PdX2oXNpJ WtcD1TN0CHy+Q== Date: Fri, 08 Aug 2025 12:10:14 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Message-ID: <87ms8a6mmn.fsf@protonmail.com> In-Reply-To: <864iujotmv.fsf@gnu.org> References: <878qk5qvob.fsf@telefonica.net> <87bjowa1w0.fsf@protonmail.com> <875xf49zm3.fsf@protonmail.com> <865xf4xuln.fsf@gnu.org> <8634a8xmaf.fsf@gnu.org> <877bzf816c.fsf@protonmail.com> <864iujotmv.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 588b0d2dec54ef702446a87be79e862b1f9bb65d MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 79131 Cc: gerd.moellmann@gmail.com, oscarfv@eclipso.eu, casouri@gmail.com, 79131@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Eli Zaretskii" writes: >> Date: Thu, 07 Aug 2025 17:58:22 +0000 >> From: Pip Cet >> Cc: Gerd M=C3=B6llmann , oscarfv@eclipso.eu, c= asouri@gmail.com, 79131@debbugs.gnu.org >> >> "Eli Zaretskii" writes: >> >> >> >> Unfortunately, while Fmemq and Fassq are easy to fix, Fget can als= o 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)? Otherwi= se, >> >> >> >> 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 08 08:39:47 2025 Received: (at 79131) by debbugs.gnu.org; 8 Aug 2025 12:39:47 +0000 Received: from localhost ([127.0.0.1]:37576 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ukMNv-00062D-3E for submit@debbugs.gnu.org; Fri, 08 Aug 2025 08:39:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60928) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ukMNr-00061z-EN for 79131@debbugs.gnu.org; Fri, 08 Aug 2025 08:39:44 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ukMNk-0004kM-Ft; Fri, 08 Aug 2025 08:39:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=pp0c/42klOfgUUl8I7E7O+9jTIxLo8pTC+lOHaunfns=; b=evP9ipuWSmsgokVv51mO aTvtnasNoUcESx09EFuV+E6LfstHyZSwze9ND2JVTinr8N4QAvFkfVVHxREqnTWSoGNxWSyu5u0L3 YixcCzJo5vyY049QHLxwZHS2JU23LrPoCeXlSL8HNfG6y4+JZRx6xF77xS64TBXum3O5s9zcmBXUV 3nEBqpMrVj2Jfvrqot4fwpezaUiJNZvnikL2b3+QkA0VPRvdSTpADjfIJlJ7SLfE9I1ZqcD0sT1Kg wH9njN+4GDVjjkcGvPoy97/BJTaRlkplEJnSzZ06e2mWIa6ZIDtXfPrkDe+aml/990Rdi1O1OlGQD SiWnMhPfz3/xyQ==; Date: Fri, 08 Aug 2025 15:39:33 +0300 Message-Id: <86bjoqng1m.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87ms8a6mmn.fsf@protonmail.com> (message from Pip Cet on Fri, 08 Aug 2025 12:10:14 +0000) Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV References: <878qk5qvob.fsf@telefonica.net> <87bjowa1w0.fsf@protonmail.com> <875xf49zm3.fsf@protonmail.com> <865xf4xuln.fsf@gnu.org> <8634a8xmaf.fsf@gnu.org> <877bzf816c.fsf@protonmail.com> <864iujotmv.fsf@gnu.org> <87ms8a6mmn.fsf@protonmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79131 Cc: gerd.moellmann@gmail.com, oscarfv@eclipso.eu, casouri@gmail.com, 79131@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 08 Aug 2025 12:10:14 +0000 > From: Pip Cet > Cc: gerd.moellmann@gmail.com, oscarfv@eclipso.eu, casouri@gmail.com, 79131@debbugs.gnu.org > > "Eli Zaretskii" writes: > > >> Date: Thu, 07 Aug 2025 17:58:22 +0000 > >> From: Pip Cet > >> Cc: Gerd Möllmann , oscarfv@eclipso.eu, casouri@gmail.com, 79131@debbugs.gnu.org > >> > >> "Eli Zaretskii" 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 08 09:08:25 2025 Received: (at 79131) by debbugs.gnu.org; 8 Aug 2025 13:08:25 +0000 Received: from localhost ([127.0.0.1]:37652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ukMpc-0007Py-Ti for submit@debbugs.gnu.org; Fri, 08 Aug 2025 09:08:25 -0400 Received: from mail-24416.protonmail.ch ([109.224.244.16]:16565) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ukMpa-0007Pf-2p for 79131@debbugs.gnu.org; Fri, 08 Aug 2025 09:08:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1754658495; x=1754917695; bh=pKESpQEDg1kvMEg9I4w/jBY4S5oclFdQWfJKX3UU/A0=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=fUABN+RlLqa7QKG2kK2Wn70MMykQT28aWUDJkl99OTBF+3wcfQ1Dq2myMGldjRx5R dAJXBTvvZ2xPDdAzdMbGTYM/cEGtB77Atih4qU1W/n+swxEnm0dvCJjF+FGuE7UvWz zh2vaHb3hupLHQTJtQx2tK7Na+2DbP5DnQyFZXRQ/nCKCVLy5ts+dKTTax3wjjDHwW IUK37bBitkO2QcqUugQEEhLa4vVrHC0o9XN09GnQ1MMtTDndZhUjvQnEIwAXKgxW1O w636j9b2fkk1RIY1ZG7NYY5sbMgx1S2pq+bT6oh/VgA5iFyI6L8Qwof3E1Wj53z/oQ YrgZCBKNxasQQ== Date: Fri, 08 Aug 2025 13:08:12 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV Message-ID: <87bjoq6jxz.fsf@protonmail.com> In-Reply-To: <86o6sqnmil.fsf@gnu.org> References: <878qk5qvob.fsf@telefonica.net> <877bzf816c.fsf@protonmail.com> <864iujotmv.fsf@gnu.org> <86tt2inxo7.fsf@gnu.org> <86qzxmnvju.fsf@gnu.org> <86o6sqnmil.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 6f1ab3ff025c961c0ebd2734fd1105657be28407 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 79131 Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= , oscarfv@eclipso.eu, casouri@gmail.com, 79131@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Eli Zaretskii" writes: >> From: Gerd M=C3=B6llmann >> Cc: pipcet@protonmail.com, oscarfv@eclipso.eu, casouri@gmail.com, >> 79131@debbugs.gnu.org >> Date: Fri, 08 Aug 2025 09:10:07 +0200 >> >> Eli Zaretskii writes: >> >> >> From: Gerd M=C3=B6llmann >> >> Cc: pipcet@protonmail.com, oscarfv@eclipso.eu, casouri@gmail.com, >> >> 79131@debbugs.gnu.org >> >> Date: Fri, 08 Aug 2025 08:25:04 +0200 >> >> >> >> Eli Zaretskii writes: >> >> >> >> >> While an algorithm is working on tree, the tree may temporarily be= come >> >> >> 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 happe= n >> >> > 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, =09=09=09=09ptrdiff_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 =3D Fcdr (XCDR (tail))) =09{ =09 Lisp_Object prop, tmp; =09 prop =3D XCAR (tail); =09 /* Is this particular property front-sticky? */ =09 if (CONSP (front) && ! NILP (Fmemq (prop, front))) <--- quit happens h= ere =09 continue; =09 /* Is this particular property rear-nonsticky? */ =09 if (CONSP (rear) && ! NILP (Fmemq (prop, rear))) =09 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 =3D=3D i->position || eobp) { ... for (temp =3D prev ? prev : i; temp; temp =3D INTERVAL_PARENT_OR_NULL= (temp)) =09{ =09 temp->total_length +=3D length; <--- adjustment happens here ... } else { for (temp =3D i; temp; temp =3D INTERVAL_PARENT_OR_NULL (temp)) =09{ =09 temp->total_length +=3D length; ... =09} } 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 =3D Qt at the wrong moment; would that help in any way? Pip From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 08 09:34:52 2025 Received: (at 79131) by debbugs.gnu.org; 8 Aug 2025 13:34:52 +0000 Received: from localhost ([127.0.0.1]:37692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ukNFD-0000IU-Px for submit@debbugs.gnu.org; Fri, 08 Aug 2025 09:34:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49506) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ukNF7-0000I9-VM for 79131@debbugs.gnu.org; Fri, 08 Aug 2025 09:34:49 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ukNF1-0007Rm-Hy; Fri, 08 Aug 2025 09:34:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=/lK2eb0LhQ3ykqoumW3atxH6fze2NWaYQ2HLiLq8xxc=; b=kUkJX0Yn9vtWePEbb/dC 83aIJkuNjfbw9dv+iMMcwkW4bWwZm/Y33DLDYJucw6HPjeYjsPYsnxKoF6tMfFhpoisDEu1YMvADk XbQz0FPEge+pyGKdCG5BqcOb6ZucO6yLPCXJCeg0oe1jNwu+Vj82gQlDetf4WjeSsABoEXfRQMS26 efDAdi8bvK2JsZTOw+0eXNuzIAqCf/lAi8MiGDDuUiwk1x1GsqQW42EGXJU7Y+AcWy/siO70omkba TJGOyBTi5XXUVfi/xb7v8mCthLjy8YOW4drFs36uEzK2jkTlCKY4Vpe0zz/frAiMuxkEoUU1QtSK+ TzUf2bq3mAymtw==; Date: Fri, 08 Aug 2025 16:34:04 +0300 Message-Id: <868qjundir.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87bjoq6jxz.fsf@protonmail.com> (message from Pip Cet on Fri, 08 Aug 2025 13:08:12 +0000) Subject: Re: bug#79131: 31.0.50; igc: nested signal, SIGSEGV References: <878qk5qvob.fsf@telefonica.net> <877bzf816c.fsf@protonmail.com> <864iujotmv.fsf@gnu.org> <86tt2inxo7.fsf@gnu.org> <86qzxmnvju.fsf@gnu.org> <86o6sqnmil.fsf@gnu.org> <87bjoq6jxz.fsf@protonmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 79131 Cc: gerd.moellmann@gmail.com, oscarfv@eclipso.eu, casouri@gmail.com, 79131@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 08 Aug 2025 13:08:12 +0000 > From: Pip Cet > Cc: Gerd Möllmann , oscarfv@eclipso.eu, casouri@gmail.com, 79131@debbugs.gnu.org > > "Eli Zaretskii" 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.