From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 17 09:34:45 2025 Received: (at submit) by debbugs.gnu.org; 17 Jan 2025 14:34:45 +0000 Received: from localhost ([127.0.0.1]:36511 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tYnQq-0008Gf-8c for submit@debbugs.gnu.org; Fri, 17 Jan 2025 09:34:45 -0500 Received: from lists.gnu.org ([2001:470:142::17]:33672) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tYnQl-0008GO-Ey for submit@debbugs.gnu.org; Fri, 17 Jan 2025 09:34:41 -0500 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 1tYnQe-0007NW-Vr for bug-gnu-emacs@gnu.org; Fri, 17 Jan 2025 09:34:33 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tYnQa-0002ES-KG for bug-gnu-emacs@gnu.org; Fri, 17 Jan 2025 09:34:32 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 818DE240027 for ; Fri, 17 Jan 2025 15:34:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1737124465; bh=y37JZ411xqFB6ytK0GDe7gsUrZI2euopPHM3w9D5zb0=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:From; b=iCtWSabLCymZ081yQ5zyWBj3Ro+qdLghUgcPN9MJWkgwIJABYZ10PcAIP+ULQCJbt 9HXYf8DP+dUnsIrJGbIBgfKq0objW1c66dskTMoyMgjT15PjQ8dsj3gnRnP2VX4pvy 5eCYu2S1yVe8UBSVgIRb/I67m4iE5jQJdZbXQr80t+58LDlms1gb9tjW/mIHwfK203 kChumkb5jBNDVtNLPoNqyvHxu8DkayANDi/cO8S+pdAQLHQOBBwIoonDRLdCE0B8EO JcbmQsmZQ/aR2qyprSsxAkIrkVGptXrKLXcB7qZwEWygBtdyftAw2knjy5mfd6J62r dhDOZCnodH8+g== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YZMgh74TJz6txZ for ; Fri, 17 Jan 2025 15:34:24 +0100 (CET) From: Ihor Radchenko To: bug-gnu-emacs@gnu.org Subject: 31.0.50; igc: Crash report X-Debbugs-Cc: Date: Fri, 17 Jan 2025 14:36:36 +0000 Message-ID: <87a5bpo6bv.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_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 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 (/) Just got the following: lockix.c:126: Emacs fatal error: assertion failed: res == 0 [Switching to Thread 0x7ffff2b71e00 (LWP 11068)] Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:432 432 { (gdb) bt #0 terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:432 #1 0x00005555557e24fb in set_state (state=IGC_STATE_DEAD) at igc.c:975 #2 igc_assert_fail (file=, line=, msg=) at igc.c:276 #3 0x000055555585f049 in mps_lib_assert_fail (condition=0x5555558c0763 "res == 0", line=126, file=0x5555558c074d "lockix.c") at /home/yantar92/Dist/mps/code/mpsliban.c:87 #4 LockClaim (lock=0x7fffe8000110) at /home/yantar92/Dist/mps/code/lockix.c:126 #5 0x000055555585f27d in ArenaEnterLock (arena=0x7ffff7fbe000, recursive=0) at /home/yantar92/Dist/mps/code/global.c:576 #6 0x000055555588812e in ArenaEnter (arena=0x7ffff7fbe000) at /home/yantar92/Dist/mps/code/global.c:553 #7 ArenaAccess (addr=0x7fff9d8709e0, mode=mode@entry=3, context=context@entry=0x7fffffff4650) at /home/yantar92/Dist/mps/code/global.c:655 #8 0x0000555555893432 in sigHandle (sig=, info=0x7fffffff4970, uap=0x7fffffff4840) at /home/yantar92/Dist/mps/code/protsgix.c:97 #9 0x00007ffff2c41100 in () at /lib64/libc.so.6 #10 0x00005555556d2273 in SDATA (string=) at /home/yantar92/Git/emacs/src/lisp.h:1758 #11 SSDATA (string=) at /home/yantar92/Git/emacs/src/lisp.h:1764 #12 handle_user_signal (sig=sig@entry=12) at keyboard.c:8315 #13 0x00005555556f1678 in deliver_process_signal (sig=12, handler=handler@entry=0x5555556d2210 ) at sysdep.c:1757 #14 0x00005555556d1134 in deliver_user_signal (sig=) at keyboard.c:8352 #15 0x00007ffff2c41100 in () at /lib64/libc.so.6 #16 0x00007ffff2d189ab in mprotect () at /lib64/libc.so.6 #17 0x000055555588183d in ProtSet (base=0x7ffe4c324000, limit=, mode=0) at /home/yantar92/Dist/mps/code/protix.c:105 #18 0x000055555588b9dc in traceScanSegRes (ts=ts@entry=1, rank=rank@entry=1, arena=arena@entry=0x7ffff7fbe000, seg=seg@entry=0x7ffe4803e5f8) at /home/yantar92/Dist/mps/code/trace.c:1204 #19 0x000055555588bbfa in traceScanSeg (ts=1, rank=1, arena=0x7ffff7fbe000, seg=0x7ffe4803e5f8) at /home/yantar92/Dist/mps/code/trace.c:1267 #20 0x000055555588c5d4 in TraceAdvance (trace=trace@entry=0x7ffff7fbeaa8) at /home/yantar92/Dist/mps/code/trace.c:1728 #21 0x000055555588ccd4 in TracePoll (workReturn=workReturn@entry=0x7fffffff58d0, collectWorldReturn=collectWorldReturn@entry=0x7fffffff58cc, globals=globals@entry=0x7ffff7fbe008, collectWorldAllowed=) at /home/yantar92/Dist/mps/code/trace.c:1849 #22 0x000055555588cf1b in ArenaPoll (globals=globals@entry=0x7ffff7fbe008) at /home/yantar92/Dist/mps/code/global.c:745 #23 0x000055555588d30a in mps_ap_fill (p_o=p_o@entry=0x7fffffff5a40, mps_ap=mps_ap@entry=0x7fffe8001980, size=size@entry=24) at /home/yantar92/Dist/mps/code/mpsi.c:1097 #24 0x00005555557ddf28 in alloc_impl (size=24, type=IGC_OBJ_CONS, ap=0x7fffe8001980) at igc.c:3956 #25 0x00005555557de04c in alloc (size=size@entry=24, type=type@entry=IGC_OBJ_CONS) at igc.c:3984 #26 0x00005555557e0964 in igc_make_cons (car=car@entry=XIL(0x7ffefc1c18a5), cdr=XIL(0x7ffdf8565feb)) at igc.c:4013 #27 0x0000555555734ee8 in Fcons (car=car@entry=XIL(0x7ffefc1c18a5), cdr=) at alloc.c:2958 #28 0x0000555555752a84 in save_restriction_save () at editfns.c:3097 #29 0x00005555557a3267 in helper_save_restriction () at comp.c:5128 #30 0x00007fffdc3efc22 in F6f72672d666f6c642d636f72652d6765742d666f6c64696e672d73706563_org_fold_core_get_folding_spec_0 () at /home/yantar92/.emacs.d/eln-cache/31.0.50-fc0e2b3f/org-fold-core-7b3a75f5-931c108c.eln #31 0x0000555555758fb3 in funcall_subr (subr=, numargs=numargs@entry=2, args=args@entry=0x7fffdedff0c0) at eval.c:3178 #32 0x000055555579fdaf in exec_byte_code (fun=, args_template=, args_template@entry=257, nargs=, nargs@entry=1, args=, args@entry=0x7fffffff5e68) at /home/yantar92/Git/emacs/src/lisp.h:2332 #33 0x000055555575ab86 in funcall_lambda (fun=XIL(0x7fff9ebde0b5), nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffffff5e68) at eval.c:3267 #34 0x000055555575af3b in funcall_general (fun=, numargs=numargs@entry=1, args=args@entry=0x7fffffff5e68) at eval.c:3059 #35 0x0000555555757198 in Ffuncall (nargs=2, args=0x7fffffff5e60) at eval.c:3108 #36 0x00007fffdf8c6a6f in F666f6e742d6c6f636b2d666f6e746966792d6b6579776f7264732d726567696f6e_font_lock_fontify_keywords_region_0 () at /home/yantar92/Git/emacs/src/../native-lisp/31.0.50-fc0e2b3f/preloaded/font-lock-895216f6-4021c0ad.eln #37 0x0000555555758fca in funcall_subr (subr=, numargs=numargs@entry=3, args=args@entry=0x7fffffff6188) at eval.c:3180 #38 0x000055555575b08a in funcall_general (fun=, numargs=numargs@entry=3, args=args@entry=0x7fffffff6188) at /home/yantar92/Git/emacs/src/lisp.h:2332 #39 0x0000555555757198 in Ffuncall (nargs=4, args=0x7fffffff6180) at eval.c:3108 #40 0x00007fffdf8c2740 in F666f6e742d6c6f636b2d64656661756c742d666f6e746966792d726567696f6e_font_lock_default_fontify_region_0 () at /home/yantar92/Git/emacs/src/../native-lisp/31.0.50-fc0e2b3f/preloaded/font-lock-895216f6-4021c0ad.eln #41 0x0000555555758fca in funcall_subr (subr=, numargs=numargs@entry=3, args=args@entry=0x7fffffff6308) at eval.c:3180 #42 0x000055555575b08a in funcall_general (fun=, numargs=numargs@entry=3, args=args@entry=0x7fffffff6308) at /home/yantar92/Git/emacs/src/lisp.h:2332 #43 0x0000555555757198 in Ffuncall (nargs=4, args=0x7fffffff6300) at eval.c:3108 #44 0x00007fffdf8c1735 in F666f6e742d6c6f636b2d666f6e746966792d726567696f6e_font_lock_fontify_region_0 () at /home/yantar92/Git/emacs/src/../native-lisp/31.0.50-fc0e2b3f/preloaded/font-lock-895216f6-4021c0ad.eln #45 0x0000555555758fca in funcall_subr (subr=, numargs=numargs@entry=2, args=args@entry=0x7fffdedff040) at eval.c:3180 #46 0x000055555579fdaf in exec_byte_code (fun=, args_template=, args_template@entry=257, nargs=, nargs@entry=1, args=, args@entry=0x7fffffff6608) at /home/yantar92/Git/emacs/src/lisp.h:2332 #47 0x000055555575ab86 in funcall_lambda (fun=XIL(0x7ffdf852f91d), nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffffff6608) at eval.c:3267 #48 0x000055555575af3b in funcall_general (fun=, numargs=numargs@entry=1, args=args@entry=0x7fffffff6608) at eval.c:3059 --Type for more, q to quit, c to continue without paging--c #49 0x0000555555757198 in Ffuncall (nargs=2, args=args@entry=0x7fffffff6600) at eval.c:3108 #50 0x000055555575777d in run_hook_wrapped_funcall (nargs=, args=0x7fffffff6600) at eval.c:2887 #51 0x00005555557562b9 in run_hook_with_args (nargs=2, args=0x7fffffff6600, funcall=funcall@entry=0x55555575775c ) at eval.c:2968 #52 0x000055555575648e in Frun_hook_wrapped (nargs=, args=) at eval.c:2902 #53 0x00007fffdf89fafa in F6a69742d6c6f636b2d2d72756e2d66756e6374696f6e73_jit_lock__run_functions_0 () at /home/yantar92/Git/emacs/src/../native-lisp/31.0.50-fc0e2b3f/preloaded/jit-lock-8a988e43-86e09700.eln #54 0x0000555555758fb3 in funcall_subr (subr=, numargs=numargs@entry=2, args=args@entry=0x7fffffff67e8) at eval.c:3178 #55 0x000055555575b08a in funcall_general (fun=, numargs=numargs@entry=2, args=args@entry=0x7fffffff67e8) at /home/yantar92/Git/emacs/src/lisp.h:2332 #56 0x0000555555757198 in Ffuncall (nargs=3, args=0x7fffffff67e0) at eval.c:3108 #57 0x00007fffdf8a03aa in F6a69742d6c6f636b2d666f6e746966792d6e6f77_jit_lock_fontify_now_0 () at /home/yantar92/Git/emacs/src/../native-lisp/31.0.50-fc0e2b3f/preloaded/jit-lock-8a988e43-86e09700.eln #58 0x0000555555758fb3 in funcall_subr (subr=, numargs=numargs@entry=2, args=args@entry=0x7fffffff69a8) at eval.c:3178 #59 0x000055555575b08a in funcall_general (fun=, numargs=numargs@entry=2, args=args@entry=0x7fffffff69a8) at /home/yantar92/Git/emacs/src/lisp.h:2332 #60 0x0000555555757198 in Ffuncall (nargs=3, args=0x7fffffff69a0) at eval.c:3108 #61 0x00007fffdf89f837 in F6a69742d6c6f636b2d66756e6374696f6e_jit_lock_function_0 () at /home/yantar92/Git/emacs/src/../native-lisp/31.0.50-fc0e2b3f/preloaded/jit-lock-8a988e43-86e09700.eln #62 0x0000555555758fa0 in funcall_subr (subr=, numargs=numargs@entry=1, args=args@entry=0x7fffffff6b68) at eval.c:3176 #63 0x000055555575b08a in funcall_general (fun=, numargs=numargs@entry=1, args=args@entry=0x7fffffff6b68) at /home/yantar92/Git/emacs/src/lisp.h:2332 #64 0x0000555555757198 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffff6b60) at eval.c:3108 #65 0x0000555555755c66 in internal_condition_case_n (bfun=bfun@entry=0x55555575708c , nargs=nargs@entry=2, args=args@entry=0x7fffffff6b60, handlers=handlers@entry=XIL(0x38), hfun=hfun@entry=0x5555555d2ae3 ) at eval.c:1707 #66 0x00005555555be7d5 in dsafe__call (inhibit_quit=inhibit_quit@entry=false, f=0x55555575708c , nargs=nargs@entry=2, args=args@entry=0x7fffffff6b60) at xdisp.c:3095 #67 0x00005555555be84a in dsafe_call1 (f=, arg=arg@entry=make_fixnum(12548850)) at xdisp.c:3125 #68 0x00005555555d1120 in handle_fontified_prop (it=) at xdisp.c:4644 #69 0x00005555555d4c6e in handle_stop (it=it@entry=0x7fffffff9500) at xdisp.c:4164 #70 0x00005555555e3318 in next_element_from_buffer (it=0x7fffffff9500) at xdisp.c:9752 #71 0x00005555555e1aad in get_next_display_element (it=it@entry=0x7fffffff9500) at xdisp.c:8308 #72 0x00005555555e2a70 in forward_to_next_line_start (it=0x7fffffff9500, skipped_p=skipped_p@entry=0x7fffffff770f, bidi_it_prev=bidi_it_prev@entry=0x0) at xdisp.c:7649 #73 0x00005555555e2f8a in reseat_at_next_visible_line_start (it=it@entry=0x7fffffff9500, on_newline_p=on_newline_p@entry=false) at xdisp.c:7780 #74 0x00005555555e07c4 in move_it_to (it=it@entry=0x7fffffff9500, to_charpos=5143293, to_x=to_x@entry=0, to_y=, to_vpos=to_vpos@entry=-1, op=op@entry=11) at xdisp.c:10964 #75 0x0000555555608676 in redisplay_window (window=XIL(0x7ffe9eccdd4d), just_this_one_p=just_this_one_p@entry=false) at xdisp.c:20258 #76 0x000055555560c4f3 in redisplay_window_0 (window=window@entry=XIL(0x7ffe9eccdd4d)) at xdisp.c:18111 #77 0x0000555555755b5e in internal_condition_case_1 (bfun=bfun@entry=0x55555560c4c0 , arg=arg@entry=XIL(0x7ffe9eccdd4d), handlers=, hfun=hfun@entry=0x5555555c24fd ) at eval.c:1651 #78 0x00005555555bfeee in redisplay_windows (window=XIL(0x7ffe9eccdd4d)) at xdisp.c:18080 #79 0x00005555555bfe9c in redisplay_windows (window=XIL(0x7ffdf43cbaed)) at xdisp.c:18074 #80 0x00005555555f2be4 in redisplay_internal () at xdisp.c:17497 #81 0x00005555555f3f3e in resize_echo_area_exactly () at xdisp.c:13017 #82 0x00005555556e4c46 in command_loop_1 () at keyboard.c:1584 #83 0x0000555555755ae6 in internal_condition_case (bfun=bfun@entry=0x5555556e4905 , handlers=handlers@entry=XIL(0xa8), hfun=hfun@entry=0x5555556d5870 ) at eval.c:1627 #84 0x00005555556d0687 in command_loop_2 (handlers=handlers@entry=XIL(0xa8)) at keyboard.c:1174 #85 0x0000555555755a21 in internal_catch (tag=tag@entry=XIL(0x153f0), func=func@entry=0x5555556d0657 , arg=arg@entry=XIL(0xa8)) at eval.c:1306 #86 0x00005555556d0634 in command_loop () at keyboard.c:1152 #87 0x00005555556d53e3 in recursive_edit_1 () at keyboard.c:760 #88 0x00005555556d578b in Frecursive_edit () at keyboard.c:843 #89 0x00005555556cf8ab in main (argc=1, argv=0x7fffffffd5d8) at emacs.c:2658 Lisp Backtrace: "org-fold-core-get-folding-spec" (0xdedff0c0) "org-activate-folds" (0xffff5e68) "font-lock-fontify-keywords-region" (0xffff6188) "font-lock-default-fontify-region" (0xffff6308) "font-lock-fontify-region" (0xdedff040) 0xf852f918 PVEC_CLOSURE "jit-lock--run-functions" (0xffff67e8) "jit-lock-fontify-now" (0xffff69a8) "jit-lock-function" (0xffff6b68) "redisplay_internal (C function)" (0x0) (gdb) (gdb) q In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.42, cairo version 1.18.2) of 2025-01-12 built on localhost Repository revision: b82707d70fd5bb78be5766e247e9629eb6553c30 Repository branch: scratch/igc Windowing system distributor 'The X.Org Foundation', version 11.0.12101014 System Description: Gentoo Linux Configured using: 'configure --with-mps=yes --with-native-compilation 'CFLAGS=-g3 -I/opt/mps/include -L/opt/mps/lib' JAVAC=/etc/java-config-2/current-system-vm/bin/javac PKG_CONFIG_PATH=/usr/share/guile-data/3.0/pkgconfig' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES MPS NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 17 09:41:09 2025 Received: (at 75632) by debbugs.gnu.org; 17 Jan 2025 14:41:09 +0000 Received: from localhost ([127.0.0.1]:36524 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tYnX2-0000CH-Gl for submit@debbugs.gnu.org; Fri, 17 Jan 2025 09:41:08 -0500 Received: from mail-40133.protonmail.ch ([185.70.40.133]:42391) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tYnWz-0000Bb-Hg for 75632@debbugs.gnu.org; Fri, 17 Jan 2025 09:41:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737124858; x=1737384058; bh=AINF/gjPSdYr0vk8EJzWgixc0b1lMqkkOGewxldSBUY=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=oKaSvOqjDUpo53V2e629PC03PveXx7Vnaq8J/ScT8taARCADk3T67zRDXqn+w4kHL 8YU3q/H3XTdpiMMRqZCVRFz+xC1pkE3AjUhy+OAbNB1MPQ+72qrVwHEzccr2ShZ1gQ L/boCjBmcO929eHBR3dV0H8DCQSs4bBcG6pmUAilz880Uex6pJo/hDBh9ZGqokDwUe skN0ngfbWK4lhWdXoKNCBDSxVyb2MJiWNp4MSdwRtr8PHIyWv+VUbKQtrSiMSXcBj+ nLqVAvl0HcsfIyUbF278OH2oJbAW8biuHPTUDBA3hcucxzI3VY5CWRHyqyMBbBssVc 5rX6MvQKxZgSg== Date: Fri, 17 Jan 2025 14:40:54 +0000 To: Ihor Radchenko From: Pip Cet Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <87cyglijvd.fsf@protonmail.com> In-Reply-To: <87a5bpo6bv.fsf@localhost> References: <87a5bpo6bv.fsf@localhost> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 2beed9f2243f9fce4d6a4cb24dc60faadec6c397 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: 75632 Cc: 75632@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 (-) "Ihor Radchenko" writes: > Just got the following: Yes, that's the signal handling bug. I'm not entirely sure why we removed the fix that was in scratch/igc, but we did, so we need another one. For a quick fix, you can add if (igc_busy_p ()) return; to handle_user_signal, which will silently ignore SIGUSR* received while MPS may have locked the arena. Pip From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 17 09:44:39 2025 Received: (at 75632) by debbugs.gnu.org; 17 Jan 2025 14:44:39 +0000 Received: from localhost ([127.0.0.1]:36537 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tYnaR-0000Kc-0w for submit@debbugs.gnu.org; Fri, 17 Jan 2025 09:44:39 -0500 Received: from mout01.posteo.de ([185.67.36.65]:59691) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tYnaM-0000Ja-PH for 75632@debbugs.gnu.org; Fri, 17 Jan 2025 09:44:36 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 13DFC240027 for <75632@debbugs.gnu.org>; Fri, 17 Jan 2025 15:44:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1737125067; bh=UvS08/wqEHHKVq0dP1iOWxp9++5K67h32jwuu5HcdD4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=gKs4PatIsGXaQUqvzXze6WQHEn0Y4gKEdPNR2ohB91C2Euf9n+pOk3dsiJL5CBJHc 8/Tia05Wtd/pfyYqCprC+ByI6aKon4IkxMPO+KGQxU6ghEHi3IhU/PKJveFgiIE+KV T7wgEyBhnx0fqFFjIErpT3rvJ9JTDgsabMn/dwcvZKWVpa2oNdST/sYP0ammXfkaPk kPZ7YzxKqsAPAJmvI+sUhBgztKmourk0emCtHM98Q0aSelcCU+OR0t33Kej1b+G7PY frnfB/uXbCdpCIwcK1xnMiC87hPO7/PdhIIzOLf2clwcaff2TcNnXoxR1m80vC/lkj aqCOADc+IfRYQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YZMvG382jz9rxD; Fri, 17 Jan 2025 15:44:26 +0100 (CET) From: Ihor Radchenko To: Pip Cet Subject: Re: bug#75632: 31.0.50; igc: Crash report In-Reply-To: <87cyglijvd.fsf@protonmail.com> References: <87a5bpo6bv.fsf@localhost> <87cyglijvd.fsf@protonmail.com> Date: Fri, 17 Jan 2025 14:46:35 +0000 Message-ID: <877c6to5v8.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: 75632@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 (---) Pip Cet writes: > "Ihor Radchenko" writes: > >> Just got the following: > > Yes, that's the signal handling bug. I'm not entirely sure why we > removed the fix that was in scratch/igc, but we did, so we need another > one. > ... > to handle_user_signal, which will silently ignore SIGUSR* received while > MPS may have locked the arena. I indeed sent SIGUSR2 just before I saw the crash. For some context (maybe irrelevant), Emacs hung while performing magit commit (C-c C-c in magit commit buffer; and the commit was actually written before the hang). It only ever happened for me on igc branch. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 17 10:26:26 2025 Received: (at 75632-done) by debbugs.gnu.org; 17 Jan 2025 15:26:27 +0000 Received: from localhost ([127.0.0.1]:38538 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tYoEs-00031n-58 for submit@debbugs.gnu.org; Fri, 17 Jan 2025 10:26:26 -0500 Received: from mail-10629.protonmail.ch ([79.135.106.29]:33571) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tYoEn-00030z-Tg for 75632-done@debbugs.gnu.org; Fri, 17 Jan 2025 10:26:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737127573; x=1737386773; bh=5gBCkcml9ymLxbnvT7U6uHd54jCyVk+uEaCtRi//U0k=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=QraR8Q1FdnldizXtK2j1Amdu1UJIsUnDCbokgBTMSYyr7wo8+jcccBfCsLRAqLbcQ N0eBWBQvVz2A9xVpfMmCh/xK/6oqipK31mzXYOOEw7jnWERKZ/KINIItqBvN4W5vAM GkEt78tS+60j1d7zglShbwBbOOtmo/9ebYHcohx9b2xNqptVHmFIJbIb//L4uQzfdh DUR25Cvem5NPlWsrn4lQYuKxKJ/aOTssi5jKJ/x+0SSmEZ0c/zLREjzc2vtSbfLuI2 xvZU++VIgFVSKdLoj+fjUvVYjOHk82uTii4UHu6YmWTarkaJTHjEgZHCS6vZZgyUPQ jJqLoO6hQnN1g== Date: Fri, 17 Jan 2025 15:26:10 +0000 To: Ihor Radchenko From: Pip Cet Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <878qr9ihry.fsf@protonmail.com> In-Reply-To: <877c6to5v8.fsf@localhost> References: <87a5bpo6bv.fsf@localhost> <87cyglijvd.fsf@protonmail.com> <877c6to5v8.fsf@localhost> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: b8db2444f672900a163cabcccaaf9fc237835811 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: 75632-done Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= , 75632-done@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 (-) "Ihor Radchenko" writes: > Pip Cet writes: > >> "Ihor Radchenko" writes: >> >>> Just got the following: >> >> Yes, that's the signal handling bug. I'm not entirely sure why we >> removed the fix that was in scratch/igc, but we did, so we need another >> one. >> ... >> to handle_user_signal, which will silently ignore SIGUSR* received while >> MPS may have locked the arena. > > I indeed sent SIGUSR2 just before I saw the crash. It'd be nice if that simply worked. I think debugging with SIGUSR* is important, so I've pushed a fix (and I'm closing this bug; if further discussion is needed, feel free to revert and reopen). > For some context (maybe irrelevant), Emacs hung while performing magit > commit (C-c C-c in magit commit buffer; and the commit was actually > written before the hang). It only ever happened for me on igc branch. Thanks! Too bad we lost that backtrace, then. If it happens again, please let us know! (I'm using magit, and I know it waits for subprocesses, so I'll go over the SIGCHLD handling code to ensure we never drop one of them). Pip From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 17 11:48:37 2025 Received: (at 75632) by debbugs.gnu.org; 17 Jan 2025 16:48:37 +0000 Received: from localhost ([127.0.0.1]:38661 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tYpWO-00071Y-FR for submit@debbugs.gnu.org; Fri, 17 Jan 2025 11:48:37 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58398) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tYpWH-000716-T0 for 75632@debbugs.gnu.org; Fri, 17 Jan 2025 11:48:33 -0500 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 1tYpWC-00014o-DD; Fri, 17 Jan 2025 11:48:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=/q2aWTUFld2GMn3vpxPQkoa3GYMMD9QkFnruqU8T8LM=; b=oP3InG37ISWn zkPBkErkrj90Iw/gEbKGa4ZDlPcI+H3jBImPlEtiltrxTrMT4q2Xa1GH8zJTRxz3F+BWZZoV1bfO6 j8bKN5nFydeeYGDRSsInFSi7W3BeL2EcRRyuoUo8jub6Lj6UbxgYOyDj2DdtHz6SfE4rEAFvkcmUF NHd0l9a5nRivxW+4uB1wBNImIXQSE0nvgETkqnz/3PX65xUzWXCfautRwSWdpV8xg9UcsUP8peKhH YSyqBOgoVQSYk3A5QXl/bP8X1Nr5FbsWw//9f+ZHYh0AUPmRjkfc8po+hTNQJL31dSaFc3mkWSr/2 OBrNUZHzr7Tfj5YJfUwmaA==; Date: Fri, 17 Jan 2025 18:48:21 +0200 Message-Id: <86cygle696.fsf@gnu.org> From: Eli Zaretskii To: Ihor Radchenko In-Reply-To: <87a5bpo6bv.fsf@localhost> (message from Ihor Radchenko on Fri, 17 Jan 2025 14:36:36 +0000) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: 75632@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 (---) > From: Ihor Radchenko > Date: Fri, 17 Jan 2025 14:36:36 +0000 > > Just got the following: > > > lockix.c:126: Emacs fatal error: assertion failed: res == 0 > [Switching to Thread 0x7ffff2b71e00 (LWP 11068)] > > Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:432 > 432 { > (gdb) bt > #0 terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:432 > #1 0x00005555557e24fb in set_state (state=IGC_STATE_DEAD) at igc.c:975 > #2 igc_assert_fail (file=, line=, msg=) at igc.c:276 > #3 0x000055555585f049 in mps_lib_assert_fail (condition=0x5555558c0763 "res == 0", line=126, file=0x5555558c074d "lockix.c") at /home/yantar92/Dist/mps/code/mpsliban.c:87 > #4 LockClaim (lock=0x7fffe8000110) at /home/yantar92/Dist/mps/code/lockix.c:126 > #5 0x000055555585f27d in ArenaEnterLock (arena=0x7ffff7fbe000, recursive=0) at /home/yantar92/Dist/mps/code/global.c:576 > #6 0x000055555588812e in ArenaEnter (arena=0x7ffff7fbe000) at /home/yantar92/Dist/mps/code/global.c:553 > #7 ArenaAccess (addr=0x7fff9d8709e0, mode=mode@entry=3, context=context@entry=0x7fffffff4650) at /home/yantar92/Dist/mps/code/global.c:655 > #8 0x0000555555893432 in sigHandle (sig=, info=0x7fffffff4970, uap=0x7fffffff4840) at /home/yantar92/Dist/mps/code/protsgix.c:97 > #9 0x00007ffff2c41100 in () at /lib64/libc.so.6 > #10 0x00005555556d2273 in SDATA (string=) at /home/yantar92/Git/emacs/src/lisp.h:1758 > #11 SSDATA (string=) at /home/yantar92/Git/emacs/src/lisp.h:1764 > #12 handle_user_signal (sig=sig@entry=12) at keyboard.c:8315 > #13 0x00005555556f1678 in deliver_process_signal (sig=12, handler=handler@entry=0x5555556d2210 ) at sysdep.c:1757 > #14 0x00005555556d1134 in deliver_user_signal (sig=) at keyboard.c:8352 Looks like Emacs got SIGUSR1 or SIGUSR2? How come? From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 17 15:32:03 2025 Received: (at 75632) by debbugs.gnu.org; 17 Jan 2025 20:32:03 +0000 Received: from localhost ([127.0.0.1]:38962 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tYt0b-0005UT-Ul for submit@debbugs.gnu.org; Fri, 17 Jan 2025 15:32:03 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55462) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tYt0Y-0005U7-MW for 75632@debbugs.gnu.org; Fri, 17 Jan 2025 15:32:00 -0500 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 1tYt0R-0001NR-My; Fri, 17 Jan 2025 15:31:51 -0500 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=LrE83PFaqomoHdVhDngBCNtijMd3XXm2CikGhpHyDgA=; b=fiovBwVCx7Mn38T4Jq+g xGTym2DIyZRb3q5SXdzSLCZjoCwbkuLd3Nb5zgvQLk1L/IbiawE6Xur8r0UYPTjzTFMolIQrP2yCM 2W16E9tIX0K9h4DiXS3Lg2E4m1J9pUq6b0LFrKYObGPb+k7IfG8Oate+jQRsgg1tJGVhbGdEhgL3y S1tmm2caOSW+AG9epSeo/iNHBzA92tOA67v7lX9W4FeoWkCpAdqb9wETOrLq2EeMAyNL5cyj2jlyX VhKSFJNyYKu6KxpiCmz3Cu45t/3/wps4C0jlfnpK7VEqu3TRKF9zgDbLcbqAdOv3nq0lIa7n8FLEr cFyRtRVScpKYTA==; Date: Fri, 17 Jan 2025 22:31:48 +0200 Message-Id: <86y0z9chcb.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <878qr9ihry.fsf@protonmail.com> (bug-gnu-emacs@gnu.org) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <87cyglijvd.fsf@protonmail.com> <877c6to5v8.fsf@localhost> <878qr9ihry.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: 75632 Cc: yantar92@posteo.net, 75632@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 (---) > Resent-To: bug-gnu-emacs@gnu.org > Cc: Gerd Möllmann , > 75632-done@debbugs.gnu.org > Date: Fri, 17 Jan 2025 15:26:10 +0000 > From: Pip Cet via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > "Ihor Radchenko" writes: > > > Pip Cet writes: > > > >> "Ihor Radchenko" writes: > >> > >>> Just got the following: > >> > >> Yes, that's the signal handling bug. I'm not entirely sure why we > >> removed the fix that was in scratch/igc, but we did, so we need another > >> one. > >> ... > >> to handle_user_signal, which will silently ignore SIGUSR* received while > >> MPS may have locked the arena. > > > > I indeed sent SIGUSR2 just before I saw the crash. > > It'd be nice if that simply worked. I think debugging with SIGUSR* is > important, so I've pushed a fix (and I'm closing this bug; if further > discussion is needed, feel free to revert and reopen). This breaks the MS-Windows build: temacs crashes as below: Loading loadup.el (source)... Dump mode: pbootstrap Using load-path (d:/gnu/git/emacs/feature/lisp d:/gnu/git/emacs/feature/lisp/emacs-lisp d:/gnu/git/emacs/feature/lisp/progmodes d:/gnu/git/emacs/feature/lisp/language d:/gnu/git/emacs/feature/lisp/international d:/gnu/git/emacs/feature/lisp/textmodes d:/gnu/git/emacs/feature/lisp/vc) Loading emacs-lisp/debug-early... Loading emacs-lisp/byte-run... Loading emacs-lisp/backquote... Loading subr... Loading keymap... Loading version... Loading widget... Loading custom... Loading emacs-lisp/map-ynp... Loading international/mule... Loading international/mule-conf... Loading env... Loading format... Loading bindings... Loading window... Loading files... Loading emacs-lisp/macroexp... Loading cus-face... Loading faces... Loading loaddefs... Loading d:/gnu/git/emacs/feature/lisp/theme-loaddefs.el (source)... Loading button... Loading emacs-lisp/cl-preloaded... Loading emacs-lisp/oclosure... Loading obarray... Loading abbrev... Loading help... Loading jka-cmpr-hook... Loading epa-hook... Loading international/mule-cmds... Loading case-table... Loading d:/gnu/git/emacs/feature/lisp/international/charprop.el (source)... Loading international/characters... Loading international/charscript... Loading international/emoji-zwj... Loading composite... Loading language/chinese... Loading language/cyrillic... Loading language/indian... Loading language/sinhala... Loading language/english... Loading language/ethiopic... Loading language/european... Loading language/czech... Loading language/slovak... Loading language/romanian... Loading language/greek... Loading language/hebrew... Loading international/cp51932... Loading international/eucjp-ms... Loading language/japanese... Loading language/korean... Loading language/lao... Loading language/tai-viet... Loading language/thai... Loading language/tibetan... Loading language/vietnamese... Loading language/misc-lang... Loading language/utf-8-lang... Loading language/georgian... Loading language/khmer... Loading language/burmese... Loading language/cham... Loading language/philippine... Loading language/indonesian... Loading indent... Loading emacs-lisp/cl-generic... Loading simple... Loading emacs-lisp/seq... Loading emacs-lisp/nadvice... Loading minibuffer... Loading frame... Loading startup... Loading term/tty-colors... Loading font-core... Loading emacs-lisp/syntax... Loading font-lock... Loading jit-lock... Loading mouse... Loading scroll-bar... Loading select... Loading emacs-lisp/timer... Loading emacs-lisp/easymenu... Loading isearch... Loading rfn-eshadow... Loading menu-bar... Loading tab-bar... Loading emacs-lisp/lisp... Loading textmodes/page... Loading register... Loading textmodes/paragraphs... Loading progmodes/prog-mode... Loading emacs-lisp/lisp-mode... Loading textmodes/text-mode... Loading textmodes/fill... Loading newcomment... Loading replace... Loading emacs-lisp/tabulated-list... Loading buff-menu... Loading fringe... Loading emacs-lisp/regexp-opt... Loading image... Loading international/fontset... Loading dnd... Loading tool-bar... Loading term/common-win... Loading w32-vars... Loading term/w32-win... Loading disp-table... Loading w32-fns... Loading ls-lisp... Loading dos-w32... Loading touch-screen... Loading mwheel... Loading progmodes/elisp-mode... Loading emacs-lisp/float-sup... Loading vc/vc-hooks... Loading vc/ediff-hook... Loading uniquify... Loading electric... Loading paren... Loading emacs-lisp/shorthands... Loading emacs-lisp/eldoc... Loading emacs-lisp/cconv... Loading cus-start... Loading tooltip... Loading international/iso-transl... Loading emacs-lisp/rmc... Loading d:/gnu/git/emacs/feature/lisp/leim/leim-list.el (source)... Finding pointers to doc strings... Finding pointers to doc strings...done Dumping under the name bootstrap-emacs.pdmp Dumping fingerprint: 18388262a2082a9a0cae7f9f7b2f954b596ec03f060bf8e73cbd63063b9a1d95 pdumper.c:939: Emacs fatal error: assertion failed: should_end >= end Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=22, backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:432 432 { (gdb) bt #0 terminate_due_to_signal (sig=sig@entry=22, backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:432 #1 0x00f836f4 in die ( msg=msg@entry=0x15369e9 "should_end >= end", file=file@entry=0x1536431 "pdumper.c", line=line@entry=939) at alloc.c:8388 #2 0x00f88e8a in dump_igc_finish_obj (ctx=ctx@entry=0xbfebd8) at pdumper.c:939 #3 0x00f8caca in dump_object_finish (sz=40, out=0xbfe990, ctx=0xbfebd8) at pdumper.c:1003 #4 dump_subr (subr=0x11611e0 , ctx=0xbfebd8) at pdumper.c:3093 #5 dump_vectorlike (offset=6440296, lv=XIL(0x11611e5), ctx=0xbfebd8) at pdumper.c:3187 #6 dump_object (ctx=ctx@entry=0xbfebd8, object=XIL(0x11611e5)) at pdumper.c:3318 #7 0x00f8e7f4 in dump_drain_copied_objects (ctx=0xbfebd8) at pdumper.c:3539 #8 Fdump_emacs_portable (filename=, track_referrers=) at pdumper.c:4524 #9 0x00fb3ecc in eval_sub (form=XIL(0xc35cedb)) at eval.c:2623 #10 0x00fb3cd9 in eval_sub (form=XIL(0xc35ce1b)) at eval.c:2571 #11 0x00fb514a in Fprogn (body=XIL(0xc35d0e3)) at eval.c:452 #12 Flet (args=) at eval.c:1122 #13 0x00fb3cd9 in eval_sub (form=XIL(0xc35cd33)) at eval.c:2571 #14 0x00fb58cc in Funwind_protect (args=XIL(0xc35d0f3)) at lisp.h:1563 #15 0x00fb3cd9 in eval_sub (form=XIL(0xc35cd23)) at eval.c:2571 #16 0x00fb514a in Fprogn (body=XIL(0)) at eval.c:452 #17 Flet (args=) at eval.c:1122 #18 0x00fb3cd9 in eval_sub (form=XIL(0xc35ccf3)) at eval.c:2571 #19 0x00fb514a in Fprogn (body=XIL(0xc35dbb3)) at eval.c:452 #20 Flet (args=) at eval.c:1122 #21 0x00fb3cd9 in eval_sub (form=XIL(0xc35c793)) at eval.c:2571 #22 0x00fb3cd9 in eval_sub (form=XIL(0xc35c773)) at eval.c:2571 #23 0x00fb48b4 in Fprogn (body=XIL(0)) at eval.c:452 #24 Fif (args=XIL(0xc35c32b)) at eval.c:408 #25 0x00fb3cd9 in eval_sub (form=form@entry=XIL(0xc35c25b)) at eval.c:2571 #26 0x00ff023c in readevalloop (readcharfun=readcharfun@entry=XIL(0x6120), infile0=infile0@entry=0xbff638, sourcename=sourcename@entry=XIL(0xb04a364), printflag=printflag@entry=false, unibyte=unibyte@entry=XIL(0), readfun=readfun@entry=XIL(0), start=start@entry=XIL(0), end=, end@entry=XIL(0)) at lread.c:2540 #27 0x00ff0cd9 in Fload (file=XIL(0xb04a004), noerror=XIL(0), nomessage=XIL(0), nosuffix=XIL(0), must_suffix=) at lisp.h:1229 #28 0x00fb3e69 in eval_sub (form=form@entry=XIL(0xb04a02b)) at eval.c:2634 #29 0x00fb5e32 in Feval (form=XIL(0xb04a02b), lexical=lexical@entry=XIL(0x20)) at eval.c:2479 #30 0x00f0ef8b in top_level_2 () at lisp.h:1229 #31 0x00fae15b in internal_condition_case ( bfun=bfun@entry=0xf0ef2c , handlers=handlers@entry=XIL(0x60), hfun=hfun@entry=0xf18d54 ) at eval.c:1627 #32 0x00f0f6b8 in top_level_1 (ignore=XIL(0)) at lisp.h:1229 #33 0x00fae077 in internal_catch (tag=tag@entry=XIL(0xc560), func=func@entry=0xf0f68c , arg=arg@entry=XIL(0)) at eval.c:1306 #34 0x00f0ed3f in command_loop () at lisp.h:1229 #35 0x00f188fa in recursive_edit_1 () at keyboard.c:760 #36 0x00f18c01 in Frecursive_edit () at keyboard.c:843 #37 0x0115fc05 in main (argc=, argv=) at emacs.c:2658 Lisp Backtrace: "dump-emacs-portable" (0xbfed90) "if" (0xbfee1c) "let" (0xbfef1c) "unwind-protect" (0xbfefcc) "let" (0xbff0bc) "let" (0xbff1ac) "if" (0xbff23c) "if" (0xbff2ec) "load" (0xbff8e0) (gdb) up #1 0x00f836f4 in die ( msg=msg@entry=0x15369e9 "should_end >= end", file=file@entry=0x1536431 "pdumper.c", line=line@entry=939) at alloc.c:8388 8388 terminate_due_to_signal (SIGABRT, INT_MAX); (gdb) #2 0x00f88e8a in dump_igc_finish_obj (ctx=ctx@entry=0xbfebd8) at pdumper.c:939 939 eassert (should_end >= end); (gdb) p should_end $1 = (gdb) p end $2 = 0x1b5c35b0 "" (gdb) p igc_dump_finish_obj (ctx->igc_obj_dumped, ctx->igc_type, base, end) value has been optimized out (gdb) p base $3 = p igc_dump_finish_obj (ctx->igc_obj_dumped, ctx->igc_type, (char *) ctx->buf + ctx->igc_base_offset, end) $4 = 0x1b5c3588 "" The following patch seems to fix that, but I'm not sure it's the correct fix. Can you explain why we need to add-variable-watcher for this in init_keyboard, in particular in temacs? since init_keyboard is called both in temacs and in emacs, it sounds like the code, when called in emacs, will try to free memory that was malloced in temacs, is that right? diff --git a/src/keyboard.c b/src/keyboard.c index 82505e7..a5d85e9 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -12817,6 +12817,7 @@ init_keyboard (void) #endif #ifdef HAVE_MPS + if (initialized) { Lisp_Object watcher; From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 17 15:53:12 2025 Received: (at 75632) by debbugs.gnu.org; 17 Jan 2025 20:53:12 +0000 Received: from localhost ([127.0.0.1]:39011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tYtL6-0006Z4-5i for submit@debbugs.gnu.org; Fri, 17 Jan 2025 15:53:12 -0500 Received: from mail-10629.protonmail.ch ([79.135.106.29]:61567) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tYtL4-0006Yh-1b for 75632@debbugs.gnu.org; Fri, 17 Jan 2025 15:53:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737147183; x=1737406383; bh=54qIZHfjKE9jg4L97UB59d3L5y9lVuaXen4yvrongB4=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=djf/H87Yt9zaxfsDzuUNGJGv7yfgFaZuQuf3Vx59jqeToa1Yd0qEnrMBh5MbJ9C+S 8Hddgb5yNa/U7Tc7uSEWuNZOr8BdwJk6SvlNoCRLaQxPk/jJavrc58Uuw85SH4A1G5 BZLhZi6YF/ydgkKwyis9Gb+JM3j7r79raATQ7S4mL39tHuQf2cZPZrGrAoSwXAoOlG CNWZs6V3kT5//TZRIvcd7YQpg2vkAdikIijbmDYhb8Wy7jbsnekm3f9cSN29hMN0HP PkA07oenSpjrelS7wbxqcTQwszKO+gOidTdfYJK/ZiXMM4HlOVzY3tmD9iZJVobuFP KhTSbV9xIByPg== Date: Fri, 17 Jan 2025 20:52:58 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <87o705f9id.fsf@protonmail.com> In-Reply-To: <86y0z9chcb.fsf@gnu.org> References: <87a5bpo6bv.fsf@localhost> <87cyglijvd.fsf@protonmail.com> <877c6to5v8.fsf@localhost> <878qr9ihry.fsf@protonmail.com> <86y0z9chcb.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 7347f070edb6d9183bd89f20b0cb87adb4735f5f 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: 75632 Cc: yantar92@posteo.net, 75632@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: >> Resent-To: bug-gnu-emacs@gnu.org >> Cc: Gerd M=C3=B6llmann , >> 75632-done@debbugs.gnu.org >> Date: Fri, 17 Jan 2025 15:26:10 +0000 >> From: Pip Cet via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> "Ihor Radchenko" writes: >> >> > Pip Cet writes: >> > >> >> "Ihor Radchenko" writes: >> >> >> >>> Just got the following: >> >> >> >> Yes, that's the signal handling bug. I'm not entirely sure why we >> >> removed the fix that was in scratch/igc, but we did, so we need anoth= er >> >> one. >> >> ... >> >> to handle_user_signal, which will silently ignore SIGUSR* received wh= ile >> >> MPS may have locked the arena. >> > >> > I indeed sent SIGUSR2 just before I saw the crash. >> >> It'd be nice if that simply worked. I think debugging with SIGUSR* is >> important, so I've pushed a fix (and I'm closing this bug; if further >> discussion is needed, feel free to revert and reopen). > > This breaks the MS-Windows build: temacs crashes as below: Sorry. Can you try the fix I just pushed? While I arrived at that independently (I was about to push when I got your email), I believe it explains your crash as well. > (gdb) bt > #0 terminate_due_to_signal (sig=3Dsig@entry=3D22, > backtrace_limit=3Dbacktrace_limit@entry=3D2147483647) at emacs.c:43= 2 > #1 0x00f836f4 in die ( > msg=3Dmsg@entry=3D0x15369e9 "should_e= nd >=3D end", > file=3Dfile@entry=3D0x1536431 "pdumper= .c", > line=3Dline@entry=3D939) at alloc.c:8388 > #2 0x00f88e8a in dump_igc_finish_obj (ctx=3Dctx@entry=3D0xbfebd8) at p= dumper.c:939 This function calls igc_dump_finish_obj, which returns 0 because the GC header for the static subr hasn't been initialized, and then causes the assertion error. > The following patch seems to fix that, but I'm not sure it's the > correct fix. Can you explain why we need to add-variable-watcher for > this in init_keyboard, in particular in temacs? I'm not sure what you are suggesting here. Is there a good place that is initialized only in the !pdumper || !temacs case? > since init_keyboard > is called both in temacs and in emacs, it sounds like the code, when > called in emacs, will try to free memory that was malloced in temacs, > is that right? I don't think so, but it might call Fadd_variable_watcher twice. We should avoid that. > diff --git a/src/keyboard.c b/src/keyboard.c > index 82505e7..a5d85e9 100644 > --- a/src/keyboard.c > +++ b/src/keyboard.c > @@ -12817,6 +12817,7 @@ init_keyboard (void) > #endif > > #ifdef HAVE_MPS > + if (initialized) > { > Lisp_Object watcher; I can add that (with a FIXME comment because it breaks the !pdumper case, which is currently an #error but appears to work). Pip From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 17 16:05:35 2025 Received: (at 75632) by debbugs.gnu.org; 17 Jan 2025 21:05:36 +0000 Received: from localhost ([127.0.0.1]:39025 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tYtX5-0007K1-Fv for submit@debbugs.gnu.org; Fri, 17 Jan 2025 16:05:35 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48592) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tYtX2-0007Jm-BQ for 75632@debbugs.gnu.org; Fri, 17 Jan 2025 16:05:34 -0500 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 1tYtWv-0006Nk-R0; Fri, 17 Jan 2025 16:05:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=rAS+q6cHMhBqUNUNlCPGbDZh7aumKcOMXvjXuKQWvR4=; b=eTwwqspp6dcM v0JzO0on0kykLzeqRVzn1TH3hlKigAcixPPCsqRahPn7dmaFNhbfRN8sKJGktrkcnupml9oU4TEO3 PlntSDtEbHyzR77ohHYfzs/owgjKWjaKjXuy+bz18QmKWY35ngVOTLXkWmwwoVwDUp/zFMO3nQrva oGFGo7+1TN4jZRwF45M3Sf/Q+I2nX+Tdm/qlkS5HM0HO3nXnbuL0EhVJQWs0T7tz2VHlwFknRaznM /BI41VXST4oAxoX1zhLUsI+jIgdcoWhXXl/Au3JR1RWteVyPruydl02Ja8MSS+XrT1jcurMrOYpd2 g+GESTlNNft0FpcJegj2lg==; Date: Fri, 17 Jan 2025 23:04:57 +0200 Message-Id: <86plklcft2.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87o705f9id.fsf@protonmail.com> (message from Pip Cet on Fri, 17 Jan 2025 20:52:58 +0000) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <87cyglijvd.fsf@protonmail.com> <877c6to5v8.fsf@localhost> <878qr9ihry.fsf@protonmail.com> <86y0z9chcb.fsf@gnu.org> <87o705f9id.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: yantar92@posteo.net, 75632@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, 17 Jan 2025 20:52:58 +0000 > From: Pip Cet > Cc: 75632@debbugs.gnu.org, yantar92@posteo.net > > "Eli Zaretskii" writes: > > > This breaks the MS-Windows build: temacs crashes as below: > > Sorry. Can you try the fix I just pushed? While I arrived at that > independently (I was about to push when I got your email), I believe it > explains your crash as well. It fixes the crash, thanks. > > The following patch seems to fix that, but I'm not sure it's the > > correct fix. Can you explain why we need to add-variable-watcher for > > this in init_keyboard, in particular in temacs? > > I'm not sure what you are suggesting here. Is there a good place that > is initialized only in the !pdumper || !temacs case? The "if (initialized)" test is exactly for that. pdumper_load sets initialized = true before it returns. So in temacs initialized will be false when init_keyboard is called. > I don't think so, but it might call Fadd_variable_watcher twice. We > should avoid that. So maybe the patch I proposed should be installed regardless. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 17 16:30:56 2025 Received: (at 75632) by debbugs.gnu.org; 17 Jan 2025 21:30:57 +0000 Received: from localhost ([127.0.0.1]:39063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tYtvc-0000AB-Bq for submit@debbugs.gnu.org; Fri, 17 Jan 2025 16:30:56 -0500 Received: from mail-40133.protonmail.ch ([185.70.40.133]:52017) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tYtvY-00009t-4h for 75632@debbugs.gnu.org; Fri, 17 Jan 2025 16:30:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737149445; x=1737408645; bh=21HX3JWE59tpTeSS/ScGbBv2Zy2VbfkRfiqkC6kAVr4=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=pvRkjVNMmo1krLUZTLM4PiDNULNIDpG18Ac2hxdG+DuDiPkl7fpAyZoGmJKEyAQzF M5cECwMX5quhHtTeHBXivfSxaj7d9vWQrxVB9ErPvN4M89B11xPcINgck4+/ZzfDQD bgRFV2aASKTAbQ/3s1X69dtOf6ADZOJPfhMrP1SBH7Nfa1z8GPnWqUkctDJC5mv8qj NeWhoRAgJQcGFdslJrET9PKmlGeJqIln4aEJ9srNmz8valPADMcIiBVJxSS15B3rPD 0p1r5hi/Mz/9i/B9/Ye9UGjJWgY7/wnvLJWDxHfNErYdLNU+vdXKgTT9BpQHqdQrBQ BNU+4wJ2EM4Yg== Date: Fri, 17 Jan 2025 21:30:41 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <87a5bpf7ri.fsf@protonmail.com> In-Reply-To: <86plklcft2.fsf@gnu.org> References: <87a5bpo6bv.fsf@localhost> <87cyglijvd.fsf@protonmail.com> <877c6to5v8.fsf@localhost> <878qr9ihry.fsf@protonmail.com> <86y0z9chcb.fsf@gnu.org> <87o705f9id.fsf@protonmail.com> <86plklcft2.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: c332aa81aae940d92c4bbb96984eadf0c882a6fc 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: 75632 Cc: yantar92@posteo.net, 75632@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: Fri, 17 Jan 2025 20:52:58 +0000 >> From: Pip Cet >> Cc: 75632@debbugs.gnu.org, yantar92@posteo.net >> >> "Eli Zaretskii" writes: >> >> > This breaks the MS-Windows build: temacs crashes as below: >> >> Sorry. Can you try the fix I just pushed? While I arrived at that >> independently (I was about to push when I got your email), I believe it >> explains your crash as well. > > It fixes the crash, thanks. Thanks! I still think we should initialize the vector header of subrs and the thread structure to contain the appropriate size fields. Subrs currently claim size 0 (and no auto-marked Lisp fields), which is confusing. Threads report totally incorrect values, because of what seems like a bug to me: VECSIZE is used where VECSIZE - PSEUDOVECSIZE is intended. But this problem was caused by the GC header, not the vectorlike header. Initializing the GC header is harder because of the hash value. (No great harm in leaving it set to 0 for those very few objects, though). >> > The following patch seems to fix that, but I'm not sure it's the >> > correct fix. Can you explain why we need to add-variable-watcher for >> > this in init_keyboard, in particular in temacs? >> >> I'm not sure what you are suggesting here. Is there a good place that >> is initialized only in the !pdumper || !temacs case? > > The "if (initialized)" test is exactly for that. pdumper_load sets > initialized =3D true before it returns. So in temacs initialized will > be false when init_keyboard is called. But if we build without pdumper (after removing the relevant #error and a few minor fixes, it works just fine), initialized is false, so SIGUSR2 wouldn't work at all in those builds. >> I don't think so, but it might call Fadd_variable_watcher twice. We >> should avoid that. > > So maybe the patch I proposed should be installed regardless. I had a look: Fadd_variable_watcher handles the case of several identical watchers by ignoring the second call. If we want to avoid calling Fadd_variable_watcher twice, we can use "if (!initialized)", which will run the code just once (however, the explicit call to watch_debug_on_event needs to be performed twice, before and after the dump, because the xstrdup()ed string isn't dumped). In the pdumper case, it'd run in temacs, put the right subr in the symbol's plist, dump it, and then it'd be restored from the dump and we'd only need the initial call. Would that be okay? Pip From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 18 02:29:13 2025 Received: (at 75632) by debbugs.gnu.org; 18 Jan 2025 07:29:13 +0000 Received: from localhost ([127.0.0.1]:39776 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tZ3Gb-00047C-C1 for submit@debbugs.gnu.org; Sat, 18 Jan 2025 02:29:13 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43974) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tZ3GX-00046x-9L for 75632@debbugs.gnu.org; Sat, 18 Jan 2025 02:29:11 -0500 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 1tZ3GR-0003Rn-5t; Sat, 18 Jan 2025 02:29:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=gnURSOCsPxQb/srOOXPXo1AACPmGC1IH6tRyLc3pERU=; b=ont7xnZzoOPo LhgX0MQR9K3LdrnGxYOPsI4KaXG1gDjgKYv07LF5cXupgr3HUZ2No+qtnZRAgFGOmh+v0lPQP54sH cgwevxKKJDjj6AbWz7RKiv7QMiMjC0HusrYXOQuMsFHXhdvzqbHRBEt6x8Z1z3O9CFkMwjYtd16yr L8t+b69urabZHeVKFOsrVDCvbU4zr2BdB08EllvyS0+DLdtkySBQ7MaeGuEgOlQd2ReD1NUJI8inY gK++kyLEQDeJhWREb1i5HV7QIJPHN6m+DNy0KIysXXMySGgWbOCucJJp0O5FRchhOEv9KtWkV57AS deRgCDsPOsziKewYs9djGA==; Date: Sat, 18 Jan 2025 09:28:55 +0200 Message-Id: <86msfod1hk.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87a5bpf7ri.fsf@protonmail.com> (message from Pip Cet on Fri, 17 Jan 2025 21:30:41 +0000) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <87cyglijvd.fsf@protonmail.com> <877c6to5v8.fsf@localhost> <878qr9ihry.fsf@protonmail.com> <86y0z9chcb.fsf@gnu.org> <87o705f9id.fsf@protonmail.com> <86plklcft2.fsf@gnu.org> <87a5bpf7ri.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: yantar92@posteo.net, 75632@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, 17 Jan 2025 21:30:41 +0000 > From: Pip Cet > Cc: 75632@debbugs.gnu.org, yantar92@posteo.net > > "Eli Zaretskii" writes: > > >> I'm not sure what you are suggesting here. Is there a good place that > >> is initialized only in the !pdumper || !temacs case? > > > > The "if (initialized)" test is exactly for that. pdumper_load sets > > initialized = true before it returns. So in temacs initialized will > > be false when init_keyboard is called. > > But if we build without pdumper (after removing the relevant #error and > a few minor fixes, it works just fine), initialized is false, so SIGUSR2 > wouldn't work at all in those builds. Do we want to support MPS in unexec builds? I thought we didn't. (Does it even work in such builds?) > In the pdumper case, it'd run in temacs, put the right subr in the > symbol's plist, dump it, and then it'd be restored from the dump and > we'd only need the initial call. > > Would that be okay? I have no idea, because I don't understand why is that the solution to SIGUSR handling. (How about adding some comments which explain the purpose of watching that variable?) Also see above regarding unexec build with MPS. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 18 06:42:58 2025 Received: (at 75632) by debbugs.gnu.org; 18 Jan 2025 11:42:59 +0000 Received: from localhost ([127.0.0.1]:40546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tZ7EA-0005mk-Dg for submit@debbugs.gnu.org; Sat, 18 Jan 2025 06:42:58 -0500 Received: from mail-10629.protonmail.ch ([79.135.106.29]:31895) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tZ7E7-0005mV-Ba for 75632@debbugs.gnu.org; Sat, 18 Jan 2025 06:42:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737200568; x=1737459768; bh=JeIxygCK43RrEKnuduRWubItG90znGOTO+ZZRacxRR0=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=ZQZPsatG2lh07GsBImjF1hdanwdNzzBo5+h7Yn44scH1DpzqszKfgQG5LRU78mpKH n1dgd52Q7gzzljDANXxBR0cA0KCSXdAAk8AifWzTekRP06NnKu08jKRuQL48SszF3g GzLXpIKgiH6c7TANd+Ak7rvi2oXpElgnglryaFjhvjmkxAQio52BRuNh+iIIiSHVMx mP0VB8durND/yEMeFicrm/ONJhTgBRUB3um71ygD///XnZvco6Q7Ff+7M8ndxs7Fyx 6sfkvPfOe0YlIyMiJeVAw0NSWsiPoKE9PKFuTj+cKsCAWzp47d21O1V0PgZqjReCnC 8/3z/vLLBTjag== Date: Sat, 18 Jan 2025 11:42:44 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <874j1we4bh.fsf@protonmail.com> In-Reply-To: <86msfod1hk.fsf@gnu.org> References: <87a5bpo6bv.fsf@localhost> <87cyglijvd.fsf@protonmail.com> <877c6to5v8.fsf@localhost> <878qr9ihry.fsf@protonmail.com> <86y0z9chcb.fsf@gnu.org> <87o705f9id.fsf@protonmail.com> <86plklcft2.fsf@gnu.org> <87a5bpf7ri.fsf@protonmail.com> <86msfod1hk.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: c4dee80d9c72b4be16863e924de56ae22573fe61 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: 75632 Cc: yantar92@posteo.net, 75632@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: Fri, 17 Jan 2025 21:30:41 +0000 >> From: Pip Cet >> Cc: 75632@debbugs.gnu.org, yantar92@posteo.net >> >> "Eli Zaretskii" writes: >> >> >> I'm not sure what you are suggesting here. Is there a good place tha= t >> >> is initialized only in the !pdumper || !temacs case? >> > >> > The "if (initialized)" test is exactly for that. pdumper_load sets >> > initialized =3D true before it returns. So in temacs initialized will >> > be false when init_keyboard is called. >> >> But if we build without pdumper (after removing the relevant #error and >> a few minor fixes, it works just fine), initialized is false, so SIGUSR2 >> wouldn't work at all in those builds. > > Do we want to support MPS in unexec builds? I thought we didn't. > (Does it even work in such builds?) I was talking about --with-dumping=3Dnone, not unexec builds. I"m not fixing unexec bugs! >> In the pdumper case, it'd run in temacs, put the right subr in the >> symbol's plist, dump it, and then it'd be restored from the dump and >> we'd only need the initial call. >> >> Would that be okay? > > I have no idea, because I don't understand why is that the solution to > SIGUSR handling. (How about adding some comments which explain the > purpose of watching that variable?) Also see above regarding unexec > build with MPS. Vdebug_on_event points to data behind a memory barrier. It's replaced by a C string which is xstrdup'd, so that's not behind a memory barrier. keeping the two in sync is done with a variable watcher, as is the case for gc-cons-threshold. Variable watchers survive dump/reload cycles, so we set it up just once, when !initialized; when entering the code in the post-dump state, we perform the initial dummy "watch" event to initialize the C string. Pip From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 18 07:25:17 2025 Received: (at 75632) by debbugs.gnu.org; 18 Jan 2025 12:25:17 +0000 Received: from localhost ([127.0.0.1]:40645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tZ7t6-0002NJ-Vy for submit@debbugs.gnu.org; Sat, 18 Jan 2025 07:25:17 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40800) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tZ7t4-0002MV-Mk for 75632@debbugs.gnu.org; Sat, 18 Jan 2025 07:25:15 -0500 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 1tZ7sy-0001VX-3W; Sat, 18 Jan 2025 07:25:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=L0PcXoiNfLx9xMg6bwqowaoGEsTJ2reUlmWo5mRTZvI=; b=MWlwTrK9WKX4 dmGGFmBDICWeIayotoem+QvVFjTs1XEr/LkQYVecIn/3KQ95JQHqv501DeouEKE0Hoz2UNiLWLHss ky9M4F3JYG6f9yrGrVFsZwq8PcjpQUXbtZnBQ+68GpkTMNJylms2ocvDeO6KprA9pxl2cjqADlyOa bcjcYAPmbwQVlChvaUbPpYSdGHNZSDP2MNitXcLk7+Uy8a+ukJobUKq3mwQBY8I25eJvA1MmRcpMn 4UuOv8kufPSVTz7n4whludtlPFyuBSaayFErmnCiU8Ux9vUjZxwBUDk7RGyBNIjMmvqE2tdpRZflu XTYKj0iR7Jo67egxGl4p/A==; Date: Sat, 18 Jan 2025 14:25:03 +0200 Message-Id: <86o7049un4.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <874j1we4bh.fsf@protonmail.com> (message from Pip Cet on Sat, 18 Jan 2025 11:42:44 +0000) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <87cyglijvd.fsf@protonmail.com> <877c6to5v8.fsf@localhost> <878qr9ihry.fsf@protonmail.com> <86y0z9chcb.fsf@gnu.org> <87o705f9id.fsf@protonmail.com> <86plklcft2.fsf@gnu.org> <87a5bpf7ri.fsf@protonmail.com> <86msfod1hk.fsf@gnu.org> <874j1we4bh.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: yantar92@posteo.net, 75632@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: Sat, 18 Jan 2025 11:42:44 +0000 > From: Pip Cet > Cc: 75632@debbugs.gnu.org, yantar92@posteo.net > > >> But if we build without pdumper (after removing the relevant #error and > >> a few minor fixes, it works just fine), initialized is false, so SIGUSR2 > >> wouldn't work at all in those builds. > > > > Do we want to support MPS in unexec builds? I thought we didn't. > > (Does it even work in such builds?) > > I was talking about --with-dumping=none, not unexec builds. I"m not > fixing unexec bugs! OK, so the only interesting use case is running temacs when not dumping it. > >> In the pdumper case, it'd run in temacs, put the right subr in the > >> symbol's plist, dump it, and then it'd be restored from the dump and > >> we'd only need the initial call. > >> > >> Would that be okay? > > > > I have no idea, because I don't understand why is that the solution to > > SIGUSR handling. (How about adding some comments which explain the > > purpose of watching that variable?) Also see above regarding unexec > > build with MPS. > > Vdebug_on_event points to data behind a memory barrier. It's replaced > by a C string which is xstrdup'd, so that's not behind a memory barrier. > keeping the two in sync is done with a variable watcher, as is the case > for gc-cons-threshold. > > Variable watchers survive dump/reload cycles, so we set it up just once, > when !initialized; when entering the code in the post-dump state, we > perform the initial dummy "watch" event to initialize the C string. OK, but what does this have to do with SIGUSR handling? From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 18 09:27:20 2025 Received: (at 75632) by debbugs.gnu.org; 18 Jan 2025 14:27:20 +0000 Received: from localhost ([127.0.0.1]:40804 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tZ9nD-0002Zm-6Y for submit@debbugs.gnu.org; Sat, 18 Jan 2025 09:27:19 -0500 Received: from mail-10631.protonmail.ch ([79.135.106.31]:39649) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tZ9n9-0002ZV-8W for 75632@debbugs.gnu.org; Sat, 18 Jan 2025 09:27:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737210428; x=1737469628; bh=YOUxyS6XCaZqk/+0BiklUp90SgY9VvxKKojV6AhfQNo=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=ohMrsDz6cgnW3Ecx9T0v6HieST1uHTlcYAl2tA9ZmkLE6GLnLPnxKmdHPsVCKXgVI VccfsAdEh58GHVQdaFPC+OS7P7F09XnG+4ftDlJlrV9FjX3YwGaUT8arL/nTbhA7Qi Qlf7nMRuOGs+6FllJwnS4mNP+LJQtEN28yx6VGDuYO2YqD14p3GGhgS1wPAlYE1tch 12v48ymHwKO8Eggif/2BlR4G9f56IfZuz3uzJRTQK2l40PpmsM23zQ2DhzSv6/q6DC RS9caYTrizPqt6gZiWWVC1SL+pYgsE/TeuCn/QOLggBdzFt8lqu4Tdh+Y5xgpowWtV xLcd4xEPTCJUQ== Date: Sat, 18 Jan 2025 14:27:03 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <875xmcci55.fsf@protonmail.com> In-Reply-To: <86o7049un4.fsf@gnu.org> References: <87a5bpo6bv.fsf@localhost> <878qr9ihry.fsf@protonmail.com> <86y0z9chcb.fsf@gnu.org> <87o705f9id.fsf@protonmail.com> <86plklcft2.fsf@gnu.org> <87a5bpf7ri.fsf@protonmail.com> <86msfod1hk.fsf@gnu.org> <874j1we4bh.fsf@protonmail.com> <86o7049un4.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 59c468604785e2cb428d44c837e5128138fc4da7 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: 75632 Cc: yantar92@posteo.net, 75632@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: Sat, 18 Jan 2025 11:42:44 +0000 >> From: Pip Cet >> Cc: 75632@debbugs.gnu.org, yantar92@posteo.net >> >> >> But if we build without pdumper (after removing the relevant #error a= nd >> >> a few minor fixes, it works just fine), initialized is false, so SIGU= SR2 >> >> wouldn't work at all in those builds. >> > >> > Do we want to support MPS in unexec builds? I thought we didn't. >> > (Does it even work in such builds?) >> >> I was talking about --with-dumping=3Dnone, not unexec builds. I"m not >> fixing unexec bugs! > > OK, so the only interesting use case is running temacs when not > dumping it. I think it's important to keep temacs/emacs without dumping runnable. It's certainly still interesting when temacs is called emacs. >> >> In the pdumper case, it'd run in temacs, put the right subr in the >> >> symbol's plist, dump it, and then it'd be restored from the dump and >> >> we'd only need the initial call. >> >> >> >> Would that be okay? >> > >> > I have no idea, because I don't understand why is that the solution to >> > SIGUSR handling. (How about adding some comments which explain the >> > purpose of watching that variable?) Also see above regarding unexec >> > build with MPS. >> >> Vdebug_on_event points to data behind a memory barrier. It's replaced >> by a C string which is xstrdup'd, so that's not behind a memory barrier. >> keeping the two in sync is done with a variable watcher, as is the case >> for gc-cons-threshold. >> >> Variable watchers survive dump/reload cycles, so we set it up just once, >> when !initialized; when entering the code in the post-dump state, we >> perform the initial dummy "watch" event to initialize the C string. > > OK, but what does this have to do with SIGUSR handling? The SIGUSR* handler needs to access that string. Signal handlers cannot access MPS-managed memory, so we need to put the string in regular xmalloc memory. I think that's clear from the commit message, by the way. If it isn't, I'd appreciate advice on how to improve it. (Maybe it's a good idea to use the extended ChangeLog format with an explanatory paragraph between the header line (which some git utilities insist on keeping shorter than it should be) and the individual files' changes.) Pip From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 18 10:50:27 2025 Received: (at 75632) by debbugs.gnu.org; 18 Jan 2025 15:50:27 +0000 Received: from localhost ([127.0.0.1]:43445 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tZB5e-0006vn-UJ for submit@debbugs.gnu.org; Sat, 18 Jan 2025 10:50:27 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60124) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tZB5c-0006va-VL for 75632@debbugs.gnu.org; Sat, 18 Jan 2025 10:50:25 -0500 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 1tZB5X-0001Kn-HM; Sat, 18 Jan 2025 10:50:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=grzAV87Tpn0yV+EnLEe0a2ondY4NTBIDwAaRnJ208EA=; b=GNcW3C4wJ4ZI WlO9yUKCxtgO7vpq4+5/i0NVfsltaYd1eYjDob4pTl/VF8OYwIiPoLUrVWw5cIoz35FDJmWjesRQy vftvf5F3YEKnIIAdceoJdyLq5sYAewK1DnXwVNLqnB1hVLSZ1F8wTQ4oyrNf/PzapIF/g+Z+xbPP6 I/9ABAD18KKfXMPwPaa0IJKoOqIx6+ekqJKjWWziyc4o8Ef5pHU7hDu48KMKrRZVx1q/9kGMGm2Fn rY6gPT1weAeDvcBrHo6hbeAJqtROedWpoutqAf4shCyofT3ZLNhmVPezR/cx8mMn4T/UJn47oFRpM jWvLPy/u4UrTGlqa7ylz9g==; Date: Sat, 18 Jan 2025 17:50:16 +0200 Message-Id: <86a5bo9l53.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <875xmcci55.fsf@protonmail.com> (message from Pip Cet on Sat, 18 Jan 2025 14:27:03 +0000) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <878qr9ihry.fsf@protonmail.com> <86y0z9chcb.fsf@gnu.org> <87o705f9id.fsf@protonmail.com> <86plklcft2.fsf@gnu.org> <87a5bpf7ri.fsf@protonmail.com> <86msfod1hk.fsf@gnu.org> <874j1we4bh.fsf@protonmail.com> <86o7049un4.fsf@gnu.org> <875xmcci55.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: yantar92@posteo.net, 75632@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: Sat, 18 Jan 2025 14:27:03 +0000 > From: Pip Cet > Cc: 75632@debbugs.gnu.org, yantar92@posteo.net > > "Eli Zaretskii" writes: > > >> I was talking about --with-dumping=none, not unexec builds. I"m not > >> fixing unexec bugs! > > > > OK, so the only interesting use case is running temacs when not > > dumping it. > > I think it's important to keep temacs/emacs without dumping runnable. > It's certainly still interesting when temacs is called emacs. Yes, of course, no argument here. > >> Vdebug_on_event points to data behind a memory barrier. It's replaced > >> by a C string which is xstrdup'd, so that's not behind a memory barrier. > >> keeping the two in sync is done with a variable watcher, as is the case > >> for gc-cons-threshold. > >> > >> Variable watchers survive dump/reload cycles, so we set it up just once, > >> when !initialized; when entering the code in the post-dump state, we > >> perform the initial dummy "watch" event to initialize the C string. > > > > OK, but what does this have to do with SIGUSR handling? > > The SIGUSR* handler needs to access that string. Signal handlers cannot > access MPS-managed memory, so we need to put the string in regular > xmalloc memory. So this is just to allow the signal handler access to the event name? I'd be much happier if we instead treated this as we treat SIGIO that is delivered when the user presses a keyboard key: set a flag saying that input is available, and then process it as we do with keyboard. The SIGUSR event is eventually entered into the keyboard buffer anyway, so why should we treat it so differently from SIGIO? > I think that's clear from the commit message, by the way. If it isn't, > I'd appreciate advice on how to improve it. These details are better said in comments to the code than in commit log messages. Looking for explanations for what the code does in Git history is less convenient, and I'm quite sure some people will not even think about it, at least not at first. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 18 12:32:13 2025 Received: (at 75632) by debbugs.gnu.org; 18 Jan 2025 17:32:13 +0000 Received: from localhost ([127.0.0.1]:43614 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tZCg8-0003Bu-LY for submit@debbugs.gnu.org; Sat, 18 Jan 2025 12:32:13 -0500 Received: from mail-40133.protonmail.ch ([185.70.40.133]:15277) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tZCg5-0003Bd-2c for 75632@debbugs.gnu.org; Sat, 18 Jan 2025 12:32:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737221522; x=1737480722; bh=xh9mlulINOqerMmPgvqmGRDPLuXEoX06zDn58vr2jnA=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=XRkwdvysVgnCi3FKUHArAmbzAzHmd5U4plDunw2Ydludyd9hDoYM7xzotRyxEDl9c aG4OVLkuOkLZHjvQYmkY268FuXVkGg9RNj67lAkzAem6zjw2FoVKQqdAsQAIcZIwwG XKnXJqZCTIzk7nALWprThAD0HCom8J3M0IvvrK9xOZ9yHIoXNIsTw7xABjcW6hRsd0 DEnlefnZwQ6xXXLF5+rUnw2ZYocBb6YrkIrB0m1qyubXgdgSym4BqP+vrWV2yt/H2h CGtP3kXgLlsV8ELIO2SkvIPOg5q66xaZuLsK8rNLQJE+Gt39YtJXSn1SMu/2JoQTDO 0HtFT065QcVtQ== Date: Sat, 18 Jan 2025 17:31:57 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <87jzasav0j.fsf@protonmail.com> In-Reply-To: <86a5bo9l53.fsf@gnu.org> References: <87a5bpo6bv.fsf@localhost> <87o705f9id.fsf@protonmail.com> <86plklcft2.fsf@gnu.org> <87a5bpf7ri.fsf@protonmail.com> <86msfod1hk.fsf@gnu.org> <874j1we4bh.fsf@protonmail.com> <86o7049un4.fsf@gnu.org> <875xmcci55.fsf@protonmail.com> <86a5bo9l53.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: ec64371081db99378271554fe4cb83c0581dcaec 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: 75632 Cc: yantar92@posteo.net, 75632@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: Sat, 18 Jan 2025 14:27:03 +0000 >> From: Pip Cet >> Cc: 75632@debbugs.gnu.org, yantar92@posteo.net >> >> "Eli Zaretskii" writes: >> >> >> I was talking about --with-dumping=3Dnone, not unexec builds. I"m no= t >> >> fixing unexec bugs! >> > >> > OK, so the only interesting use case is running temacs when not >> > dumping it. >> >> I think it's important to keep temacs/emacs without dumping runnable. >> It's certainly still interesting when temacs is called emacs. > > Yes, of course, no argument here. So (!initialized) it is? That works for temacs and emacs (I originally thought it would be wasteful for non-interactive temacs, but I'm sure someone's using that :-) ). >> >> Vdebug_on_event points to data behind a memory barrier. It's replace= d >> >> by a C string which is xstrdup'd, so that's not behind a memory barri= er. >> >> keeping the two in sync is done with a variable watcher, as is the ca= se >> >> for gc-cons-threshold. >> >> >> >> Variable watchers survive dump/reload cycles, so we set it up just on= ce, >> >> when !initialized; when entering the code in the post-dump state, we >> >> perform the initial dummy "watch" event to initialize the C string. >> > >> > OK, but what does this have to do with SIGUSR handling? >> >> The SIGUSR* handler needs to access that string. Signal handlers cannot >> access MPS-managed memory, so we need to put the string in regular >> xmalloc memory. > > So this is just to allow the signal handler access to the event name? So it can determine whether to set some flags, or mark an input signal pending and set some other flags, yes. > I'd be much happier if we instead treated this as we treat SIGIO that > is delivered when the user presses a keyboard key: set a flag saying > that input is available, and then process it as we do with keyboard. IIRC, there are some loops that test Vinhibit_quit or Vquit_flag directly (or use QUITP); we wouldn't be able to break out of one of those if we only set Vinhibit_quit from what's currently store_user_signal_events, would we? If we want to change behavior in this way, we should do it on master, then merge it into feature/igc. > The SIGUSR event is eventually entered into the keyboard buffer > anyway, so why should we treat it so differently from SIGIO? Vdebug_on_event isn't, AFAICS. Not a major change to make it so, though. I don't know why we eat this event, but we do. >> I think that's clear from the commit message, by the way. If it isn't, >> I'd appreciate advice on how to improve it. > > These details are better said in comments to the code than in commit > log messages. Looking for explanations for what the code does in Git > history is less convenient, and I'm quite sure some people will not > even think about it, at least not at first. Good point, agreed. Pip From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 18 13:57:30 2025 Received: (at 75632) by debbugs.gnu.org; 18 Jan 2025 18:57:30 +0000 Received: from localhost ([127.0.0.1]:43768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tZE0g-00072J-3O for submit@debbugs.gnu.org; Sat, 18 Jan 2025 13:57:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50548) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tZE0d-000720-KW for 75632@debbugs.gnu.org; Sat, 18 Jan 2025 13:57:28 -0500 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 1tZE0Q-0008D8-TR; Sat, 18 Jan 2025 13:57:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=pkpEMV5zYxztlhg5r2U8QWMV5mLWxF5dN2PSARvPwU4=; b=a5eVpaYbG8qQ JO17XB6vk6PP4lKJV+nVqcCg9r+K8fjgl71RDVVr9AfOWHQ7zH5AR1teKuPFuokOxtPvKb3Kp1bhs ZbfIzvzutR0De/hH+dqilnQ1RltObnz8QiCwCkztW7ZQHfwiSqcNYxZk53rtMLsVWMsp92slOwIkH ZyjeLJ54kg2t1M87CfAbNamd67Vf+/tgFmyr/BcKYvSrc3nStiqUGT1tgKCJkEy3w/91DR134aLNE GiT24sFWDVjYIjYHkX4HIc9goHl2tPCvG9VLGmgz3SDBj/GIB0Pv/tCSZsVuaaS3Ddua9bJJTLzSh tbZTL1DzS7Hg5i8Wuf6hPg==; Date: Sat, 18 Jan 2025 20:57:01 +0200 Message-Id: <864j1w9chu.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87jzasav0j.fsf@protonmail.com> (message from Pip Cet on Sat, 18 Jan 2025 17:31:57 +0000) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <87o705f9id.fsf@protonmail.com> <86plklcft2.fsf@gnu.org> <87a5bpf7ri.fsf@protonmail.com> <86msfod1hk.fsf@gnu.org> <874j1we4bh.fsf@protonmail.com> <86o7049un4.fsf@gnu.org> <875xmcci55.fsf@protonmail.com> <86a5bo9l53.fsf@gnu.org> <87jzasav0j.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: yantar92@posteo.net, 75632@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: Sat, 18 Jan 2025 17:31:57 +0000 > From: Pip Cet > Cc: 75632@debbugs.gnu.org, yantar92@posteo.net > > "Eli Zaretskii" writes: > > >> I think it's important to keep temacs/emacs without dumping runnable. > >> It's certainly still interesting when temacs is called emacs. > > > > Yes, of course, no argument here. > > So (!initialized) it is? That works for temacs and emacs (I originally > thought it would be wasteful for non-interactive temacs, but I'm sure > someone's using that :-) ). As long as we understand well what it means to free in emacs a string that was xstrdup'ed in temacs, yes. Suppose debug-on-event is changed in emacs to something else, how would xfree work in that case? > > I'd be much happier if we instead treated this as we treat SIGIO that > > is delivered when the user presses a keyboard key: set a flag saying > > that input is available, and then process it as we do with keyboard. > > IIRC, there are some loops that test Vinhibit_quit or Vquit_flag > directly (or use QUITP); we wouldn't be able to break out of one of > those if we only set Vinhibit_quit from what's currently > store_user_signal_events, would we? Sorry, I don't follow. Why does it matter whether we set those variables from a signal handler or in gobble_input? > > The SIGUSR event is eventually entered into the keyboard buffer > > anyway, so why should we treat it so differently from SIGIO? > > Vdebug_on_event isn't, AFAICS. Not a major change to make it so, > though. I don't know why we eat this event, but we do. I guess because we want the debugger to pop up before any queued events are processed. But I don't see why doing the same in gobble_input should produce different behavior. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 18 14:54:08 2025 Received: (at 75632) by debbugs.gnu.org; 18 Jan 2025 19:54:08 +0000 Received: from localhost ([127.0.0.1]:43840 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tZEtT-00018y-OO for submit@debbugs.gnu.org; Sat, 18 Jan 2025 14:54:08 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]:35217) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tZEtQ-00018Q-9A for 75632@debbugs.gnu.org; Sat, 18 Jan 2025 14:54:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737230037; x=1737489237; bh=f6p1cJb6n6Oqhn0+ZAkq9eJ5UNEjAulIHzAjgSZdy/M=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=H+XOlL/Ja7VuJBSu6Jg7jgE0nt163udQ0s+A9GT218njtMoKI1YFBmXf7LmySUIWh YkHVjq+t6KE+4z9GYft7Ue1fyYxXEcpHUagHBJeyMQp6E6t9flSEPxiX2zFZSAMbhs 1fuPCM2PgIVCZWBcyuRG+3XwBeBAhm3wVBeElzbm8p2pvt7GxGxQfc71jgUix+OBEv CgiGg5WTZ0Uod78RJTlOT1WOxmktR9KieDDqqmnXCn4IPRrJxqdUTStPpaXvJgnB5r XNiRUwjJkGDfVFJIMKz7fszNsbCeW4Jza71K424WbwPM7vzQ9y27jQZgf1pq6wRgiB oVC6bY6tja8ZA== Date: Sat, 18 Jan 2025 19:53:50 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <877c6rc30l.fsf@protonmail.com> In-Reply-To: <864j1w9chu.fsf@gnu.org> References: <87a5bpo6bv.fsf@localhost> <87a5bpf7ri.fsf@protonmail.com> <86msfod1hk.fsf@gnu.org> <874j1we4bh.fsf@protonmail.com> <86o7049un4.fsf@gnu.org> <875xmcci55.fsf@protonmail.com> <86a5bo9l53.fsf@gnu.org> <87jzasav0j.fsf@protonmail.com> <864j1w9chu.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 1f7aa3032192ca088555104732c6604c11f55f2e 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: 75632 Cc: yantar92@posteo.net, 75632@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: Sat, 18 Jan 2025 17:31:57 +0000 >> From: Pip Cet >> Cc: 75632@debbugs.gnu.org, yantar92@posteo.net >> >> "Eli Zaretskii" writes: >> >> >> I think it's important to keep temacs/emacs without dumping runnable. >> >> It's certainly still interesting when temacs is called emacs. >> > >> > Yes, of course, no argument here. >> >> So (!initialized) it is? That works for temacs and emacs (I originally >> thought it would be wasteful for non-interactive temacs, but I'm sure >> someone's using that :-) ). > > As long as we understand well what it means to free in emacs a string > that was xstrdup'ed in temacs, yes. Suppose debug-on-event is changed > in emacs to something else, how would xfree work in that case? pdumper doesn't work that way (unexec did, I think): a static variable that isn't "remembered" by pdumper isn't saved, and it starts out as NULL in the dumped Emacs, and is replaced by the new xstrdup. The old xstrdup (and the memory it allocated) are gone after the dump. >> > I'd be much happier if we instead treated this as we treat SIGIO that >> > is delivered when the user presses a keyboard key: set a flag saying >> > that input is available, and then process it as we do with keyboard. >> >> IIRC, there are some loops that test Vinhibit_quit or Vquit_flag >> directly (or use QUITP); we wouldn't be able to break out of one of >> those if we only set Vinhibit_quit from what's currently >> store_user_signal_events, would we? > > Sorry, I don't follow. Why does it matter whether we set those > variables from a signal handler or in gobble_input? We might never reach gobble_input if the variable isn't set in the signal handler: some loops check QUITP (etc.), and if there's a bug in them and Vinhibit_quit is set, the loop might never call maybe_quit. For example, SIGUSR2 should be able to interrupt this loop in gap_right: while (1) { /* I gets number of characters left to copy. */ i =3D bytepos - new_s1; if (i =3D=3D 0) =09break; /* If a quit is requested, stop copying now. =09 Change BYTEPOS to be where we have actually moved the gap to. =09 Note that this cannot happen when we are called to make the =09 gap larger or smaller, since make_gap_larger and =09 make_gap_smaller set inhibit-quit. */ if (QUITP) =09{ /* FIXME: This can point in the middle of a multibyte character. = */ =09 bytepos =3D new_s1; =09 charpos =3D BYTE_TO_CHAR (bytepos); =09 break; =09} /* Move at most 32000 chars before checking again for a quit. */ if (i > 32000) =09i =3D 32000; new_s1 +=3D i; memmove (to, from, i); from +=3D i, to +=3D i; } Since QUITP is defined as #define QUITP (!NILP (Vquit_flag) && NILP (Vinhibit_quit)) that means the signal handler (not gobble_input) needs to touch these flags. It's possible to add something like if (pending_signals) { ptrdiff_t old_bytepos =3D bytepos; ptrdiff_t old_charpos =3D charpos; bytepos =3D new_s1; charpos =3D BYTE_TO_CHAR (bytepos); maybe_quit (); } to this loop, and then it would be interruptible by SIGUSR2, but it would also be interruptible by other input events, so I'm not sure that wouldn't cause crashes. >> > The SIGUSR event is eventually entered into the keyboard buffer >> > anyway, so why should we treat it so differently from SIGIO? >> >> Vdebug_on_event isn't, AFAICS. Not a major change to make it so, >> though. I don't know why we eat this event, but we do. > > I guess because we want the debugger to pop up before any queued > events are processed. "instead of", I think. That's a detail I don't care much for: I think it'd be helpful for sigusr2 to show up in M-x view-lossage even if it triggered the debugger. > But I don't see why doing the same in > gobble_input should produce different behavior. while (true) { while (!QUITP); maybe_quit(); ) should be interruptible by SIGUSR2. Pip From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 18 15:18:32 2025 Received: (at 75632) by debbugs.gnu.org; 18 Jan 2025 20:18:32 +0000 Received: from localhost ([127.0.0.1]:43881 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tZFH6-0002MG-15 for submit@debbugs.gnu.org; Sat, 18 Jan 2025 15:18:32 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47780) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tZFH3-0002M0-CT for 75632@debbugs.gnu.org; Sat, 18 Jan 2025 15:18:30 -0500 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 1tZFGw-0001zV-88; Sat, 18 Jan 2025 15:18:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=2ttK+dV0qqmXOKc0ICd00gwidmumw51bZrw3wChcaRI=; b=JFMhiO9m1mUZ ztiRFxZt8qp/zFnsJWXD7SSENzj0dUOqQsi4wPmhb8BYHCpsmcDVEPjDgzRSdwST8C7GJDMVvri+t SvLlqfkujY/cemmnt/ktG9C/i8aUXZszmyaswvI6RzipcHstPA0m41FCkEdBRgKrkcWmCf1zCyL+q SlDdg+aZLelqT/4GWi2DtlnH17VGe/o75UzvnHl8uUDATE0D9AsmFDt8XHu4EM0WFwAzCu4KAEMi3 EC/bNf6ckJXQD6mIsJhmdwJmB2fXoO/H44b5+cv5vOwYmPO3I4rBLw2kUYAcd+66SP4lq3XwphZna T7Xo0/h28DP3SDDpSTNwxQ==; Date: Sat, 18 Jan 2025 22:18:16 +0200 Message-Id: <861pwzanav.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <877c6rc30l.fsf@protonmail.com> (message from Pip Cet on Sat, 18 Jan 2025 19:53:50 +0000) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <87a5bpf7ri.fsf@protonmail.com> <86msfod1hk.fsf@gnu.org> <874j1we4bh.fsf@protonmail.com> <86o7049un4.fsf@gnu.org> <875xmcci55.fsf@protonmail.com> <86a5bo9l53.fsf@gnu.org> <87jzasav0j.fsf@protonmail.com> <864j1w9chu.fsf@gnu.org> <877c6rc30l.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: yantar92@posteo.net, 75632@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: Sat, 18 Jan 2025 19:53:50 +0000 > From: Pip Cet > Cc: 75632@debbugs.gnu.org, yantar92@posteo.net > > "Eli Zaretskii" writes: > > >> So (!initialized) it is? That works for temacs and emacs (I originally > >> thought it would be wasteful for non-interactive temacs, but I'm sure > >> someone's using that :-) ). > > > > As long as we understand well what it means to free in emacs a string > > that was xstrdup'ed in temacs, yes. Suppose debug-on-event is changed > > in emacs to something else, how would xfree work in that case? > > pdumper doesn't work that way (unexec did, I think): a static variable > that isn't "remembered" by pdumper isn't saved, and it starts out as > NULL in the dumped Emacs, and is replaced by the new xstrdup. The old > xstrdup (and the memory it allocated) are gone after the dump. But if we use !initialized, the code which installs the variable watcher will not run in the dumped Emacs, right? > >> IIRC, there are some loops that test Vinhibit_quit or Vquit_flag > >> directly (or use QUITP); we wouldn't be able to break out of one of > >> those if we only set Vinhibit_quit from what's currently > >> store_user_signal_events, would we? > > > > Sorry, I don't follow. Why does it matter whether we set those > > variables from a signal handler or in gobble_input? > > We might never reach gobble_input if the variable isn't set in the > signal handler: some loops check QUITP (etc.), and if there's a bug in > them and Vinhibit_quit is set, the loop might never call maybe_quit. Then how about setting Vquit_flag and resetting Vinhibit_quit in the handler, but leaving the check whether we should call the debugger to gobble_input? From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 18 15:41:02 2025 Received: (at 75632) by debbugs.gnu.org; 18 Jan 2025 20:41:03 +0000 Received: from localhost ([127.0.0.1]:43911 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tZFcs-0003Q2-8c for submit@debbugs.gnu.org; Sat, 18 Jan 2025 15:41:02 -0500 Received: from mail-10629.protonmail.ch ([79.135.106.29]:27017) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tZFcp-0003PJ-5o for 75632@debbugs.gnu.org; Sat, 18 Jan 2025 15:41:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737232851; x=1737492051; bh=9YVcSwmnlrZ5u/u6NBaIwxGctT3wr0sWOuulOJ6SgjM=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=AjSY8SJZM9O0GXizlOlUS53SlL/buBHRz5DOmAkR/PVroeJaOhOrhoU5uWdKT9swZ U6i6a0QZavlEPyEK7zqM700ifyBI3sGw0h31tU81rViPNCQDnim/PxGln/l3WCtDtC GmcFqaVjXgFNm4EEQNVlmgFYrPu2QMu5NkbltXgesgdm5MsXB4hPq21SHHfLjRer8Q okqdyi4nVKe9R1ZvBsObomGw6WtAl5nYd+/uBbL0aoJwzUtlCOUPOUGOSeEDeOOyOu pW2Pim8BTH1Zs/vM96tJUas5S0/sRfeDmzdyCHhNeq2Pm+dn0oVHFqt9H3FlgCIJGD 1GvDkN2Ny7LWA== Date: Sat, 18 Jan 2025 20:40:47 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <87sepfam9u.fsf@protonmail.com> In-Reply-To: <861pwzanav.fsf@gnu.org> References: <87a5bpo6bv.fsf@localhost> <874j1we4bh.fsf@protonmail.com> <86o7049un4.fsf@gnu.org> <875xmcci55.fsf@protonmail.com> <86a5bo9l53.fsf@gnu.org> <87jzasav0j.fsf@protonmail.com> <864j1w9chu.fsf@gnu.org> <877c6rc30l.fsf@protonmail.com> <861pwzanav.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 43b9df2d3c394230deb3a27904916a13a6af04a9 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: 75632 Cc: yantar92@posteo.net, 75632@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: Sat, 18 Jan 2025 19:53:50 +0000 >> From: Pip Cet >> Cc: 75632@debbugs.gnu.org, yantar92@posteo.net >> >> "Eli Zaretskii" writes: >> >> >> So (!initialized) it is? That works for temacs and emacs (I original= ly >> >> thought it would be wasteful for non-interactive temacs, but I'm sure >> >> someone's using that :-) ). >> > >> > As long as we understand well what it means to free in emacs a string >> > that was xstrdup'ed in temacs, yes. Suppose debug-on-event is changed >> > in emacs to something else, how would xfree work in that case? >> >> pdumper doesn't work that way (unexec did, I think): a static variable >> that isn't "remembered" by pdumper isn't saved, and it starts out as >> NULL in the dumped Emacs, and is replaced by the new xstrdup. The old >> xstrdup (and the memory it allocated) are gone after the dump. > > But if we use !initialized, the code which installs the variable > watcher will not run in the dumped Emacs, right? Correct. Variable watchers are symbol properties, and symbol properties are restored from the dump, so there is no need to add them again. >> >> IIRC, there are some loops that test Vinhibit_quit or Vquit_flag >> >> directly (or use QUITP); we wouldn't be able to break out of one of >> >> those if we only set Vinhibit_quit from what's currently >> >> store_user_signal_events, would we? >> > >> > Sorry, I don't follow. Why does it matter whether we set those >> > variables from a signal handler or in gobble_input? >> >> We might never reach gobble_input if the variable isn't set in the >> signal handler: some loops check QUITP (etc.), and if there's a bug in >> them and Vinhibit_quit is set, the loop might never call maybe_quit. > > Then how about setting Vquit_flag and resetting Vinhibit_quit in the > handler, but leaving the check whether we should call the debugger to > gobble_input? 1. We can't do that unconditionally. An ordinary SIGUSR2 should not cause a quit, only a special event should. So we need to check whether the event we received is special or not. 2. probably_quit handles the quit flag first, then handles pending signals only when it is called again, by the next maybe_quit. That means by the time we reach gobble_input, it's too late to call the debugger. So we need to set debug_* at the same time as setting Vquit_flag (or rewrite probably_quit, which probably has very good reasons for its peculiar behavior). Pip From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 19 00:39:48 2025 Received: (at 75632) by debbugs.gnu.org; 19 Jan 2025 05:39:48 +0000 Received: from localhost ([127.0.0.1]:44527 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tZO2F-00087d-Tr for submit@debbugs.gnu.org; Sun, 19 Jan 2025 00:39:48 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37608) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tZO2C-00087E-Ih for 75632@debbugs.gnu.org; Sun, 19 Jan 2025 00:39:45 -0500 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 1tZO26-0001u5-J9; Sun, 19 Jan 2025 00:39:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=uC7l6rQN40yDl6OYsVLb77m8bqP1bol41TrrBYXnink=; b=Mv7+sPO40mgW 12VyU5W/q/v1hWZNpqPSaVF0GF29Yz2ozDs1CP1eylGnZURkjIY9nFOYVOQvR/8Il7PEHmKbM32dI yWlCh9Qx/gGCXmq48RK0+ipwIDMLTU5qW0U0CHl/ZGhysCOOfvZiDVhfOXZCOI2D5cctRj9Aa5Dc2 wDAt6teS0a95N+V+XGWnMcWRV+J3c8QONWc0jmBEGkzYVAkygHc5T46Q3w6LVmIHlaKjZe2gKgu6M WSsajvSLUcg+9JlCP8U4562fDM9wvLilwqS1BDxr0W5m4ESfbSSnTQb2XACvDT4yiixXzekP+mQp+ 3jtExR6xq1Xgqo5L3RSAEw==; Date: Sun, 19 Jan 2025 07:39:34 +0200 Message-Id: <86v7ub8iqx.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87sepfam9u.fsf@protonmail.com> (message from Pip Cet on Sat, 18 Jan 2025 20:40:47 +0000) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <874j1we4bh.fsf@protonmail.com> <86o7049un4.fsf@gnu.org> <875xmcci55.fsf@protonmail.com> <86a5bo9l53.fsf@gnu.org> <87jzasav0j.fsf@protonmail.com> <864j1w9chu.fsf@gnu.org> <877c6rc30l.fsf@protonmail.com> <861pwzanav.fsf@gnu.org> <87sepfam9u.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: yantar92@posteo.net, 75632@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: Sat, 18 Jan 2025 20:40:47 +0000 > From: Pip Cet > Cc: 75632@debbugs.gnu.org, yantar92@posteo.net > > "Eli Zaretskii" writes: > > > But if we use !initialized, the code which installs the variable > > watcher will not run in the dumped Emacs, right? > > Correct. Variable watchers are symbol properties, and symbol properties > are restored from the dump, so there is no need to add them again. Then why do we need to do this in C and not in Lisp? Can't we set up the watcher as part of some preloaded Lisp file? > >> >> IIRC, there are some loops that test Vinhibit_quit or Vquit_flag > >> >> directly (or use QUITP); we wouldn't be able to break out of one of > >> >> those if we only set Vinhibit_quit from what's currently > >> >> store_user_signal_events, would we? > >> > > >> > Sorry, I don't follow. Why does it matter whether we set those > >> > variables from a signal handler or in gobble_input? > >> > >> We might never reach gobble_input if the variable isn't set in the > >> signal handler: some loops check QUITP (etc.), and if there's a bug in > >> them and Vinhibit_quit is set, the loop might never call maybe_quit. > > > > Then how about setting Vquit_flag and resetting Vinhibit_quit in the > > handler, but leaving the check whether we should call the debugger to > > gobble_input? > > 1. We can't do that unconditionally. An ordinary SIGUSR2 should not > cause a quit, only a special event should. So we need to check whether > the event we received is special or not. > > 2. probably_quit handles the quit flag first, then handles pending > signals only when it is called again, by the next maybe_quit. That > means by the time we reach gobble_input, it's too late to call the > debugger. So we need to set debug_* at the same time as setting > Vquit_flag (or rewrite probably_quit, which probably has very good > reasons for its peculiar behavior). OK, but could we at least make this somewhat cleaner? Instead of copying the name of the event aside, can we produce a C integer that identifies the event, and store that number instead? Accessing integers from a signal handler should not be a problem, right? (In retrospect, we should have probably made debug-on-event a function, then we could produce that number inside the function, thus avoiding the need for watching the variable. Maybe we should introduce the function now and deprecate the variable?) From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 19 04:44:43 2025 Received: (at 75632) by debbugs.gnu.org; 19 Jan 2025 09:44:43 +0000 Received: from localhost ([127.0.0.1]:44937 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tZRrG-00069R-E6 for submit@debbugs.gnu.org; Sun, 19 Jan 2025 04:44:43 -0500 Received: from mail-4322.protonmail.ch ([185.70.43.22]:18623) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tZRrC-000697-IM for 75632@debbugs.gnu.org; Sun, 19 Jan 2025 04:44:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737279871; x=1737539071; bh=T8ma193+CFUkgRqTGxsrDPojv0ecgJS9kPOetz/BwLI=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=Wqf0Qi2eqA0oK3idH/enqYYU+pRXmz458rB/IvId0UHGdKuPS6cqay3s23u9o6WCb Q2plHHNlVgvh3bRy+g00oq8uUwPZQ6pEE2j/OfFLVsxlbjCiW0CJX5i+EadOxYbHqa 9DlxHik/tWa9rozurQzaDYaWCzJXFIOMqN1UDvU+n6klKwdvL3g/8bd9hO/B3FbKqs 2tqNFocCH/+o1OCwfxKRn2wTxEF4rlFeD3ykjRO8Sw3oTdUPHqnfmZXKFfPhXkN3Qy 1Vcn+4uJwfCksnhvJowyAYwXuUn4FDKsWZeMmUkPyr+wVeMRWcxEAh8NQWJsi/7M4B xttYLZLydVfVA== Date: Sun, 19 Jan 2025 09:44:26 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <87ldv72l5l.fsf@protonmail.com> In-Reply-To: <86v7ub8iqx.fsf@gnu.org> References: <87a5bpo6bv.fsf@localhost> <875xmcci55.fsf@protonmail.com> <86a5bo9l53.fsf@gnu.org> <87jzasav0j.fsf@protonmail.com> <864j1w9chu.fsf@gnu.org> <877c6rc30l.fsf@protonmail.com> <861pwzanav.fsf@gnu.org> <87sepfam9u.fsf@protonmail.com> <86v7ub8iqx.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 860fbea919266a7173232aa97ef8595c1a0e5165 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 75632 Cc: yantar92@posteo.net, 75632@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: -2.8 (--) "Eli Zaretskii" writes: >> Date: Sat, 18 Jan 2025 20:40:47 +0000 >> From: Pip Cet >> Cc: 75632@debbugs.gnu.org, yantar92@posteo.net >> >> "Eli Zaretskii" writes: >> >> > But if we use !initialized, the code which installs the variable >> > watcher will not run in the dumped Emacs, right? >> >> Correct. Variable watchers are symbol properties, and symbol properties >> are restored from the dump, so there is no need to add them again. > > Then why do we need to do this in C and not in Lisp? Can't we set up > the watcher as part of some preloaded Lisp file? > >> >> >> IIRC, there are some loops that test Vinhibit_quit or Vquit_flag >> >> >> directly (or use QUITP); we wouldn't be able to break out of one o= f >> >> >> those if we only set Vinhibit_quit from what's currently >> >> >> store_user_signal_events, would we? >> >> > >> >> > Sorry, I don't follow. Why does it matter whether we set those >> >> > variables from a signal handler or in gobble_input? >> >> >> >> We might never reach gobble_input if the variable isn't set in the >> >> signal handler: some loops check QUITP (etc.), and if there's a bug i= n >> >> them and Vinhibit_quit is set, the loop might never call maybe_quit. >> > >> > Then how about setting Vquit_flag and resetting Vinhibit_quit in the >> > handler, but leaving the check whether we should call the debugger to >> > gobble_input? >> >> 1. We can't do that unconditionally. An ordinary SIGUSR2 should not >> cause a quit, only a special event should. So we need to check whether >> the event we received is special or not. >> >> 2. probably_quit handles the quit flag first, then handles pending >> signals only when it is called again, by the next maybe_quit. That >> means by the time we reach gobble_input, it's too late to call the >> debugger. So we need to set debug_* at the same time as setting >> Vquit_flag (or rewrite probably_quit, which probably has very good >> reasons for its peculiar behavior). > > OK, but could we at least make this somewhat cleaner? Instead of I see no reason for why the old code behaved as it did, so I'm proposing this: 1. doc change: don't use "special event" to mean two totally different things in process_special_events and special_event_name; remove special_event_name. 2. when debug-on-event is modified/called, set a per-signal flag in the user_signal_info struct, saving us a strcmp. 3. Add a watcher as on feature/igc to reset the flags of all user signals. 4. Make that watcher callable as Fdebug_on_event directly. I stopped there. I'm confused about input_available_clear_time: it's only cleared if we don't enter the debugger. Adding the code to clear it to the debug_on_event case might help us break out of some broken pselects, and it shouldn't ever hurt us (famous last words). But maybe I totally misunderstood what you suggested, too. diff --git a/src/keyboard.c b/src/keyboard.c index fa19c9f8ad3..217ec6582fc 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -8254,6 +8254,10 @@ deliver_input_available_signal (int sig) /* Signal number. */ int sig; =20 + /* True if this event is supposed to make us enter the debugger + instead of its normal behavior. */ + bool debug_on_event; + /* Name of the signal. */ char *name; =20 @@ -8279,6 +8283,7 @@ add_user_signal (int sig, const char *name) =20 p =3D xmalloc (sizeof *p); p->sig =3D sig; + p->debug_on_event =3D false; p->name =3D xstrdup (name); p->npending =3D 0; p->next =3D user_signals; @@ -8288,42 +8293,68 @@ add_user_signal (int sig, const char *name) sigaction (sig, &action, 0); } =20 +DEFUN ("debug_on_event", Fdebug_on_event, Sdebug_on_event, 1, 4, 0, + doc: /* Make EVENT enter the debugger. + +EVENT should be a symbol, either sigusr1 or sigusr2. + +This function supports an additional calling convention to be usable as +a variable watcher. */) + (Lisp_Object arg_or_symbol, Lisp_Object newval, Lisp_Object operation, + Lisp_Object where) +{ + Lisp_Object ret =3D Qnil; + Lisp_Object symbol =3D arg_or_symbol; + if (EQ (symbol, Qdebug_on_event)) + symbol =3D newval; + + CHECK_SYMBOL (symbol); + + struct user_signal_info *p; + for (p =3D user_signals; p; p =3D p->next) + if (SYMBOLP (symbol) && strcmp (SSDATA (SYMBOL_NAME (symbol)), p->name= ) =3D=3D 0) + { +=09p->debug_on_event =3D true; +=09ret =3D Qt; + } + else + p->debug_on_event =3D false; + + Vdebug_on_event =3D symbol; + + return ret; +} + static void handle_user_signal (int sig) { struct user_signal_info *p; - const char *special_event_name =3D NULL; - - if (SYMBOLP (Vdebug_on_event)) - special_event_name =3D SSDATA (SYMBOL_NAME (Vdebug_on_event)); =20 for (p =3D user_signals; p; p =3D p->next) if (p->sig =3D=3D sig) { - if (special_event_name -=09 && strcmp (special_event_name, p->name) =3D=3D 0) +=09if (p->debug_on_event) { /* Enter the debugger in many ways. */ debug_on_next_call =3D true; debug_on_quit =3D true; Vquit_flag =3D Qt; Vinhibit_quit =3D Qnil; - - /* Eat the event. */ - break; } - -=09p->npending++; -#if defined (USABLE_SIGIO) || defined (USABLE_SIGPOLL) -=09if (interrupt_input) -=09 handle_input_available_signal (sig); =09else -#endif =09 { -=09 /* Tell wait_reading_process_output that it needs to wake -=09 up and look around. */ -=09 if (input_available_clear_time) -=09 *input_available_clear_time =3D make_timespec (0, 0); +=09 p->npending++; +#if defined (USABLE_SIGIO) || defined (USABLE_SIGPOLL) +=09 if (interrupt_input) +=09 handle_input_available_signal (sig); +=09 else +#endif +=09 { +=09=09/* Tell wait_reading_process_output that it needs to wake +=09=09 up and look around. */ +=09=09if (input_available_clear_time) +=09=09 *input_available_clear_time =3D make_timespec (0, 0); +=09 } =09 } =09break; } @@ -12755,6 +12786,16 @@ init_keyboard (void) poll_suppress_count =3D 1; start_polling (); #endif + + DEFSYM (Qdebug_on_event, "debug-on-event"); + + /* Variable watchers persist across the dump, no need to add them + twice. */ + if (!initialized) + { + Fadd_variable_watcher (Qdebug_on_event, Qdebug_on_event); + } + Fdebug_on_event (Qdebug_on_event, Vdebug_on_event, Qnil, Qnil); } =20 /* This type's only use is in syms_of_keyboard, to put properties on the @@ -13139,6 +13180,7 @@ syms_of_keyboard (void) defsubr (&Sevent_symbol_parse_modifiers); defsubr (&Sevent_convert_list); defsubr (&Sinternal_handle_focus_in); + defsubr (&Sdebug_on_event); defsubr (&Sread_key_sequence); defsubr (&Sread_key_sequence_vector); defsubr (&Srecursive_edit); > copying the name of the event aside, can we produce a C integer that > identifies the event, and store that number instead? Accessing Sorry, I ignored this when writing the patch. I don't think we should hardcode any assumptions about signal numbers, and I don't see another readily available integer we can use; in any case, it's now trivial to modify debug-on-event so several events enter the debugger. This might be handy for the Android port, which, IIUC, currently binds triple-volume-down to quit, not to enter the debugger. (I think all other ports have stable signal handling interfaces, but I may be wrong). > integers from a signal handler should not be a problem, right? (In > retrospect, we should have probably made debug-on-event a function, > then we could produce that number inside the function, thus avoiding > the need for watching the variable. Maybe we should introduce the > function now and deprecate the variable?) I've introduced a function, so you can call debug-on-event or set it, but I haven't deprecated the variable yet, because there's no way to read the value from Lisp otherwise. With this change, we still have six (!) debug-on-* variables, and two additional debug-on-* functions. They all behave slightly differently. Is this at all what you meant? I realize it's incomplete, but it's probably worth it to do things properly. Pip From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 19 05:39:04 2025 Received: (at 75632) by debbugs.gnu.org; 19 Jan 2025 10:39:05 +0000 Received: from localhost ([127.0.0.1]:45014 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tZShs-0003e9-D4 for submit@debbugs.gnu.org; Sun, 19 Jan 2025 05:39:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49916) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tZShp-0003dc-1y for 75632@debbugs.gnu.org; Sun, 19 Jan 2025 05:39:02 -0500 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 1tZShh-0005zQ-H3; Sun, 19 Jan 2025 05:38:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Ak2GGVHcLuAv+fDNgtB+GG13WUeDGKjswOIjhE0cJCk=; b=KiGZ8UluCXCQ 7t3R3hZynAXDAhIQq9qwJhwN464pNUQN1GMxhqGs02At5W7cU+YZd45iVA70WMI9rEZsGRi7H0QQy gfMUKrGG4q797FRED70QYb55IBAWBs40xNuvQBEO+vm+nof90KMlBjx6ZW882s/jFTiBH+g9u8IdQ NFTFtcdkafuHTwsq8f15P0KtM9WJ/t+2cC0pVP9L5K+/GBem44P0zOwkUJaYyhPfCKU3NbBiHKNyC jhptB7De7DyCbCmANSioSZNN+5glgZmx/B1jZ+qWgu7buiAlG4YPnfv+meTvTSlG7S9im64vjd9iZ vbYC1xJBco53/tQ6UxQx0w==; Date: Sun, 19 Jan 2025 12:38:49 +0200 Message-Id: <868qr784w6.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87ldv72l5l.fsf@protonmail.com> (message from Pip Cet on Sun, 19 Jan 2025 09:44:26 +0000) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <875xmcci55.fsf@protonmail.com> <86a5bo9l53.fsf@gnu.org> <87jzasav0j.fsf@protonmail.com> <864j1w9chu.fsf@gnu.org> <877c6rc30l.fsf@protonmail.com> <861pwzanav.fsf@gnu.org> <87sepfam9u.fsf@protonmail.com> <86v7ub8iqx.fsf@gnu.org> <87ldv72l5l.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: yantar92@posteo.net, 75632@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, 19 Jan 2025 09:44:26 +0000 > From: Pip Cet > Cc: 75632@debbugs.gnu.org, yantar92@posteo.net > > "Eli Zaretskii" writes: > > > OK, but could we at least make this somewhat cleaner? Instead of > > I see no reason for why the old code behaved as it did, so I'm proposing > this: > > 1. doc change: don't use "special event" to mean two totally different > things in process_special_events and special_event_name; remove > special_event_name. > > 2. when debug-on-event is modified/called, set a per-signal flag in the > user_signal_info struct, saving us a strcmp. > > 3. Add a watcher as on feature/igc to reset the flags of all user > signals. Can we add the watcher in Lisp instead? Are there any reasons to have it in C and at temacs time? Also, perhaps make the function debug-on-event call the watcher, not itself be the watcher. I think that might make the API cleaner. The watcher function doesn't have to be exposed to Lisp, btw. > 4. Make that watcher callable as Fdebug_on_event directly. > > I stopped there. I'm confused about input_available_clear_time: it's > only cleared if we don't enter the debugger. Adding the code to clear > it to the debug_on_event case might help us break out of some broken > pselects, and it shouldn't ever hurt us (famous last words). > > But maybe I totally misunderstood what you suggested, too. No, I think you understood me. > +DEFUN ("debug_on_event", Fdebug_on_event, Sdebug_on_event, 1, 4, 0, > + doc: /* Make EVENT enter the debugger. > + > +EVENT should be a symbol, either sigusr1 or sigusr2. > + > +This function supports an additional calling convention to be usable as > +a variable watcher. */) > + (Lisp_Object arg_or_symbol, Lisp_Object newval, Lisp_Object operation, > + Lisp_Object where) There's no EVENT in the function's arguments. And what are the other arguments? The last two seem to be unused? > + if (p->debug_on_event) > { > /* Enter the debugger in many ways. */ > debug_on_next_call = true; > debug_on_quit = true; > Vquit_flag = Qt; > Vinhibit_quit = Qnil; > - > - /* Eat the event. */ > - break; Why did you remove this last part? With the change to a flag, we no longer have a problem that requires delaying the event processing, right? So why risk the change in behavior, something that you warned against when I suggested the same? > Sorry, I ignored this when writing the patch. I don't think we should > hardcode any assumptions about signal numbers, and I don't see another > readily available integer we can use I thought about just inventing one. But that's a moot point if we go with the flag approach. > > integers from a signal handler should not be a problem, right? (In > > retrospect, we should have probably made debug-on-event a function, > > then we could produce that number inside the function, thus avoiding > > the need for watching the variable. Maybe we should introduce the > > function now and deprecate the variable?) > > I've introduced a function, so you can call debug-on-event or set it, > but I haven't deprecated the variable yet, because there's no way to > read the value from Lisp otherwise. Yes, good. We should also deprecate the usage of the variable, in the doc string and in the manual. > With this change, we still have six (!) debug-on-* variables, and two > additional debug-on-* functions. They all behave slightly differently. > > Is this at all what you meant? I realize it's incomplete, but it's > probably worth it to do things properly. Yes, that's going in the right direction, I think. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 19 08:37:32 2025 Received: (at 75632) by debbugs.gnu.org; 19 Jan 2025 13:37:32 +0000 Received: from localhost ([127.0.0.1]:45278 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tZVUZ-0001Xp-Ks for submit@debbugs.gnu.org; Sun, 19 Jan 2025 08:37:32 -0500 Received: from mail-4322.protonmail.ch ([185.70.43.22]:41953) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tZVUW-0001XY-DK for 75632@debbugs.gnu.org; Sun, 19 Jan 2025 08:37:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737293842; x=1737553042; bh=/k7ZKAyLW4U6x+kyiIunc3/hzWCKSJiGoLtorZHnSj8=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=jUocBVqg+1bDtZ2JzScQ++36fPN/RNe8ELdrCK+5jIyXI7usS6hZqcKPTuwSsTSpZ W2o6Hsq9iBsEx39qf6ufWnfAtlgoxpi0NRl0/Y5kOR0HRqReHjCLxPCZ/mGaNPoMjZ dcw+8NQipJ0CEcWa7CF2DCJGZq/MakrI8f91DGdqfTPPYZvExIZQ3R/C1SwpNrB+Ul QbCUza3nhcEAUl4pk0xwf9AsL/oS/sTmJiXB056W5imLoxY8CwNXO4ZZL3iXKrMRQG VQCVR2twxG9uWCjbcubC4eTeYMZWt5m8xA5jy0aMn6rk7E3iXDWC4mjH/x74Kh0PJu XDZZm88e+wihA== Date: Sun, 19 Jan 2025 13:37:18 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <87sepf0vt2.fsf@protonmail.com> In-Reply-To: <868qr784w6.fsf@gnu.org> References: <87a5bpo6bv.fsf@localhost> <87jzasav0j.fsf@protonmail.com> <864j1w9chu.fsf@gnu.org> <877c6rc30l.fsf@protonmail.com> <861pwzanav.fsf@gnu.org> <87sepfam9u.fsf@protonmail.com> <86v7ub8iqx.fsf@gnu.org> <87ldv72l5l.fsf@protonmail.com> <868qr784w6.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 5f9697c6446e42a3910c45e3e1f775daa3392aa4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 75632 Cc: yantar92@posteo.net, 75632@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: -2.8 (--) "Eli Zaretskii" writes: >> Date: Sun, 19 Jan 2025 09:44:26 +0000 >> From: Pip Cet >> Cc: 75632@debbugs.gnu.org, yantar92@posteo.net >> >> "Eli Zaretskii" writes: >> >> > OK, but could we at least make this somewhat cleaner? Instead of >> >> I see no reason for why the old code behaved as it did, so I'm proposing >> this: >> >> 1. doc change: don't use "special event" to mean two totally different >> things in process_special_events and special_event_name; remove >> special_event_name. >> >> 2. when debug-on-event is modified/called, set a per-signal flag in the >> user_signal_info struct, saving us a strcmp. >> >> 3. Add a watcher as on feature/igc to reset the flags of all user >> signals. > > Can we add the watcher in Lisp instead? Yes, please. That way, we could have a proper interactive form, and the current watcher could use an "internal" name (--). > Are there any reasons to have it in C Not that I can think of, but there are plenty of reasons to add it from Lisp instead. > and at temacs time? I don't think it's a realistic scenario that someone needs to debug non-interactive temacs, cannot use the default signal, and wants to change it. > Also, perhaps make the function debug-on-event call the watcher, not > itself be the watcher. I think that might make the API cleaner. The You've lost me there. I was thinking debug-on-event, a Lisp function, calls debug--on-event, a C subr, and we also install, from Lisp, a variable watcher on the deprecated debug-on-event variable. No static subrs, which would have prevented the bug. > watcher function doesn't have to be exposed to Lisp, btw. I'd just use an anonymous lambda constructed in Lisp? Causes a problem, see below. >> +DEFUN ("debug_on_event", Fdebug_on_event, Sdebug_on_event, 1, 4, 0, ^ ^ fixing that, of course. >> + doc: /* Make EVENT enter the debugger. >> + >> +EVENT should be a symbol, either sigusr1 or sigusr2. >> + >> +This function supports an additional calling convention to be usable as >> +a variable watcher. */) >> + (Lisp_Object arg_or_symbol, Lisp_Object newval, Lisp_Object operation= , >> + Lisp_Object where) > > There's no EVENT in the function's arguments. And what are the other > arguments? The last two seem to be unused? Yes, that was a failed attempt to make the DEFUN satisfy both the variable watcher API and be callable from Lisp. Bad idea. >> +=09if (p->debug_on_event) >> { >> /* Enter the debugger in many ways. */ >> debug_on_next_call =3D true; >> debug_on_quit =3D true; >> Vquit_flag =3D Qt; >> Vinhibit_quit =3D Qnil; >> - >> - /* Eat the event. */ >> - break; > > Why did you remove this last part? With the change to a flag, we no > longer have a problem that requires delaying the event processing, > right? > So why risk the change in behavior, something that you warned > against when I suggested the same? No behavior change intended! The new code is: =09if (p->debug_on_event) { /* Enter the debugger in many ways. */ debug_on_next_call =3D true; debug_on_quit =3D true; Vquit_flag =3D Qt; Vinhibit_quit =3D Qnil; } =09else =09 { ... =09 } =09break; So we hit the "break" statement just as we did in the original code, unless I'm very confused. I misread the code originally (missed the "break", and thought we always cleared the select timeout; I still think that's what we *should* do). >> Is this at all what you meant? I realize it's incomplete, but it's >> probably worth it to do things properly. > > Yes, that's going in the right direction, I think. Thanks. Before you read the patch: bindings.el doesn't seem like the best place for this code; it's related to signal handlers, and I added a comment while I was there, but I couldn't find one right away. Any suggestions? As little C code as possible, and we'll just run with the default signal handler until Lisp fixes it. Potentially separate bug: In emacs -Q, the variable documentation contains the bytecode representation of the lambda watcher: Calls these functions when changed: (#[1028 \300%3!\207 [debug--on-event]= 6=20 (fn SYMBOL NEWVAL OPERATION WHERE)]) I don't think ordinary Emacs users can read byte-code objects. I certainly cannot. Should we fix that in the documentation code, work around it by naming the watcher, or both? diff --git a/lisp/bindings.el b/lisp/bindings.el index 9987f28c027..628a71d2b4c 100644 --- a/lisp/bindings.el +++ b/lisp/bindings.el @@ -1642,7 +1642,37 @@ ctl-x-4-map (define-key ctl-x-4-map "c" 'clone-indirect-buffer-other-window) =20 ;; Signal handlers +(defun debug-on-event (event) + "Make EVENT enter the debugger. + +When Emacs receives the event specified as the argument to this +function, it will try to break into the debugger as soon as possible +instead of processing the event normally through `special-event-map'. + +EVENT should be a symbol, either `sigusr1' or `sigusr2', or nil." + (debug--on-event event)) + +(defvar debug-on-event 'sigusr2 + "Enter debugger on this event. +When Emacs receives the event specified by this variable, +it will try to break into the debugger as soon as possible instead +of processing the event normally through `special-event-map'. + +Currently, the only supported values for this +variable are `sigusr1' and `sigusr2'.") + +(make-obsolete-variable + 'debug-on-event + "use the function `debug-on-event' instead." + "31.0") + +(add-variable-watcher 'debug-on-event + (lambda (_symbol newval _operation _where) + (debug--on-event newval))) =0C+ (define-key special-event-map [sigusr1] 'ignore) +;; SIGUSR2, by default, invokes the debugger directly, so this binding +;; is ignored. (define-key special-event-map [sigusr2] 'ignore) =20 ;; Text conversion diff --git a/src/keyboard.c b/src/keyboard.c index fa19c9f8ad3..36a18976029 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -8254,6 +8254,10 @@ deliver_input_available_signal (int sig) /* Signal number. */ int sig; =20 + /* True if this event is supposed to make us enter the debugger + instead of being treated as an input event. */ + bool debug_on_event; + /* Name of the signal. */ char *name; =20 @@ -8280,6 +8284,7 @@ add_user_signal (int sig, const char *name) p =3D xmalloc (sizeof *p); p->sig =3D sig; p->name =3D xstrdup (name); + p->debug_on_event =3D !strcmp (p->name, "sigusr2"); p->npending =3D 0; p->next =3D user_signals; user_signals =3D p; @@ -8288,42 +8293,56 @@ add_user_signal (int sig, const char *name) sigaction (sig, &action, 0); } =20 +DEFUN ("debug--on-event", Fdebug__on_event, Sdebug__on_event, 1, 1, 0, + doc: /* Internal function: use debug-on-event instead. */) + (Lisp_Object event) +{ + Lisp_Object ret =3D Qnil; + CHECK_SYMBOL (event); + + struct user_signal_info *p; + for (p =3D user_signals; p; p =3D p->next) + if (strcmp (SSDATA (SYMBOL_NAME (event)), p->name) =3D=3D 0) + { +=09p->debug_on_event =3D true; +=09ret =3D Qt; + } + else + p->debug_on_event =3D false; + + return ret; +} + static void handle_user_signal (int sig) { struct user_signal_info *p; - const char *special_event_name =3D NULL; - - if (SYMBOLP (Vdebug_on_event)) - special_event_name =3D SSDATA (SYMBOL_NAME (Vdebug_on_event)); =20 for (p =3D user_signals; p; p =3D p->next) if (p->sig =3D=3D sig) { - if (special_event_name -=09 && strcmp (special_event_name, p->name) =3D=3D 0) +=09if (p->debug_on_event) { /* Enter the debugger in many ways. */ debug_on_next_call =3D true; debug_on_quit =3D true; Vquit_flag =3D Qt; Vinhibit_quit =3D Qnil; - - /* Eat the event. */ - break; } - -=09p->npending++; -#if defined (USABLE_SIGIO) || defined (USABLE_SIGPOLL) -=09if (interrupt_input) -=09 handle_input_available_signal (sig); =09else -#endif =09 { -=09 /* Tell wait_reading_process_output that it needs to wake -=09 up and look around. */ -=09 if (input_available_clear_time) -=09 *input_available_clear_time =3D make_timespec (0, 0); +=09 p->npending++; +#if defined (USABLE_SIGIO) || defined (USABLE_SIGPOLL) +=09 if (interrupt_input) +=09 handle_input_available_signal (sig); +=09 else +#endif +=09 { +=09=09/* Tell wait_reading_process_output that it needs to wake +=09=09 up and look around. */ +=09=09if (input_available_clear_time) +=09=09 *input_available_clear_time =3D make_timespec (0, 0); +=09 } =09 } =09break; } @@ -13139,6 +13158,7 @@ syms_of_keyboard (void) defsubr (&Sevent_symbol_parse_modifiers); defsubr (&Sevent_convert_list); defsubr (&Sinternal_handle_focus_in); + defsubr (&Sdebug__on_event); defsubr (&Sread_key_sequence); defsubr (&Sread_key_sequence_vector); defsubr (&Srecursive_edit); @@ -13787,17 +13807,6 @@ syms_of_keyboard (void) Vselection_inhibit_update_commands =3D list2 (Qhandle_switch_frame, Qhandle_select_window); =20 - DEFVAR_LISP ("debug-on-event", - Vdebug_on_event, - doc: /* Enter debugger on this event. -When Emacs receives the special event specified by this variable, -it will try to break into the debugger as soon as possible instead -of processing the event normally through `special-event-map'. - -Currently, the only supported values for this -variable are `sigusr1' and `sigusr2'. */); - Vdebug_on_event =3D Qsigusr2; - DEFVAR_BOOL ("attempt-stack-overflow-recovery", attempt_stack_overflow_recovery, doc: /* If non-nil, attempt to recover from C stack overflo= ws. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 19 08:46:11 2025 Received: (at 75632) by debbugs.gnu.org; 19 Jan 2025 13:46:11 +0000 Received: from localhost ([127.0.0.1]:45293 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tZVcw-0001xK-Ht for submit@debbugs.gnu.org; Sun, 19 Jan 2025 08:46:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52774) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tZVcq-0001wf-Eo for 75632@debbugs.gnu.org; Sun, 19 Jan 2025 08:46:05 -0500 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 1tZVck-00073M-3Y; Sun, 19 Jan 2025 08:45:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=4nvNjHhktP++YrBPoOOu2hKak3MbSGq34U8G1W7DXlA=; b=CYGuFyJ2WA4g v5depH99NRPiV6gimBgzvMucufgRAzEvVXAVZ7QO3ox8m8lFaaBio2WdEUAz8qttyLKbSopAEgudQ OzF9F6vjvMy8ca/HawglHiwcCLt4XqII5yycbld8tW4twAyrctHNx1jIECmuWls1KvTWPbyfGAKhp CJTelMrHC8f2J5pX29V4ZsSJDBn6SD53SIiIGx/1zZiPWYeGPwyx628n+mYDRJOqM0tGArGpM3Bmi k6QPwazICXDO3FDlqdzq/4MqJbTkp2YYhcGbmcO79FMQ4+pqNeMymnsMVJIRBk4m9m3pN5vyLVXDB dPIQrmfaS5WLvrLJg6Zgpg==; Date: Sun, 19 Jan 2025 15:45:55 +0200 Message-Id: <86plki7w8c.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87sepf0vt2.fsf@protonmail.com> (message from Pip Cet on Sun, 19 Jan 2025 13:37:18 +0000) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <87jzasav0j.fsf@protonmail.com> <864j1w9chu.fsf@gnu.org> <877c6rc30l.fsf@protonmail.com> <861pwzanav.fsf@gnu.org> <87sepfam9u.fsf@protonmail.com> <86v7ub8iqx.fsf@gnu.org> <87ldv72l5l.fsf@protonmail.com> <868qr784w6.fsf@gnu.org> <87sepf0vt2.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: yantar92@posteo.net, 75632@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, 19 Jan 2025 13:37:18 +0000 > From: Pip Cet > Cc: 75632@debbugs.gnu.org, yantar92@posteo.net > > "Eli Zaretskii" writes: > > > and at temacs time? > > I don't think it's a realistic scenario that someone needs to debug > non-interactive temacs, cannot use the default signal, and wants to > change it. I meant the interactive temacs, which begins by loading all the preloaded packages. So one of those could add the watcher. > > Also, perhaps make the function debug-on-event call the watcher, not > > itself be the watcher. I think that might make the API cleaner. The > > You've lost me there. I was thinking debug-on-event, a Lisp function, > calls debug--on-event, a C subr, and we also install, from Lisp, a > variable watcher on the deprecated debug-on-event variable. That's what I meant, yes. > Before you read the patch: bindings.el doesn't seem like the best place > for this code; it's related to signal handlers, and I added a comment > while I was there, but I couldn't find one right away. Any suggestions? One of the first files we load in loadup, I think? Like subr.el, perhaps? > Potentially separate bug: > > In emacs -Q, the variable documentation contains the bytecode > representation of the lambda watcher: > > Calls these functions when changed: (#[1028 \300%3!\207 [debug--on-event] 6 > > (fn SYMBOL NEWVAL OPERATION WHERE)]) > > I don't think ordinary Emacs users can read byte-code objects. I > certainly cannot. It's not optimal, indeed. See a somewhat better arrangement we have with the variables which should trigger redisplay of the current buffer, at the end of frame.el. > Should we fix that in the documentation code, work around it by naming > the watcher, or both? See above: changing the way we call the watcher is probably easier, and yields satisfactory results. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 07:31:06 2025 Received: (at 75632) by debbugs.gnu.org; 22 Jan 2025 12:31:06 +0000 Received: from localhost ([127.0.0.1]:60581 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1taZsu-0006Bf-Nf for submit@debbugs.gnu.org; Wed, 22 Jan 2025 07:31:06 -0500 Received: from mail-10631.protonmail.ch ([79.135.106.31]:24007) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1taZso-0005mp-IZ for 75632@debbugs.gnu.org; Wed, 22 Jan 2025 07:31:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737549051; x=1737808251; bh=o8zKbr1zjQjrPO93WR7YmW9UBTZXgo6HSK8GS91mo34=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=YYuc3yyaqvcBKVydUZwc9nk/792qYcgzUPjaXu8mcvlmMPxtny+kTOq85SHhY/QMq rO0ARa0Ve6A/CpyMSGiToGt+PxnXtOFK2jq4QIE0XwI/mcHbNAbhymMZlI0i8I5+Kk AOVJTB+YYWBCOxQKyJZSRpGyY4kXCHwmpaIqChe3CG87XPDNHzzlubWKMCj6qDOnOw hhtYFGRQpxWDprcmeXM5u8yrl4rCyLwx1fZdOWXA/njTeFXq/SwUM6hl05i6crPl/L GJ41qE+NvLOATHBe/4lKFZd2V8Mw/EdM0Wy8Y+VZGsyyW2YS03B80zBky710cBoqRw wGbkDle6Hmm2g== Date: Wed, 22 Jan 2025 12:30:45 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <87tt9rc9oz.fsf@protonmail.com> In-Reply-To: <86plki7w8c.fsf@gnu.org> References: <87a5bpo6bv.fsf@localhost> <877c6rc30l.fsf@protonmail.com> <861pwzanav.fsf@gnu.org> <87sepfam9u.fsf@protonmail.com> <86v7ub8iqx.fsf@gnu.org> <87ldv72l5l.fsf@protonmail.com> <868qr784w6.fsf@gnu.org> <87sepf0vt2.fsf@protonmail.com> <86plki7w8c.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 2bad595644fd5afc7b32648d3740fbb02788b68d 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: 75632 Cc: yantar92@posteo.net, 75632@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: Sun, 19 Jan 2025 13:37:18 +0000 >> From: Pip Cet >> Cc: 75632@debbugs.gnu.org, yantar92@posteo.net >> >> "Eli Zaretskii" writes: >> >> > and at temacs time? >> >> I don't think it's a realistic scenario that someone needs to debug >> non-interactive temacs, cannot use the default signal, and wants to >> change it. > > I meant the interactive temacs, which begins by loading all the > preloaded packages. So one of those could add the watcher. Do we really need this to be added early? If you need another signal before loadup finishes, you're modifying early Lisp anyway, and then you can just call the builtin function rather than use the variable. >> > Also, perhaps make the function debug-on-event call the watcher, not >> > itself be the watcher. I think that might make the API cleaner. The >> >> You've lost me there. I was thinking debug-on-event, a Lisp function, >> calls debug--on-event, a C subr, and we also install, from Lisp, a >> variable watcher on the deprecated debug-on-event variable. > > That's what I meant, yes. I also tried to move debug-on-event (both the variable and the function) to debug.el, which seems the most natural place. The watcher is added in bindings.el, because that's the second place people will look in when trying to figure out how to bind sigusr2 to a different event. >> Before you read the patch: bindings.el doesn't seem like the best place >> for this code; it's related to signal handlers, and I added a comment >> while I was there, but I couldn't find one right away. Any suggestions? > > One of the first files we load in loadup, I think? Like subr.el, > perhaps? See above. I think if you need to put an --eval '(debug--on-event (quote sigusr1))' in your temacs invocation, you're likely knowledgeable enough to do so. The only case that's really different is temacs -nl: it would probably behave differently if it worked (to the extend bare temacs even does). temacs -nl fixable, but I'll wait for a response before looking into doing that properly. Might not be worth it. >> Potentially separate bug: >> >> In emacs -Q, the variable documentation contains the bytecode >> representation of the lambda watcher: >> >> Calls these functions when changed: (#[1028 \300%3!\207 [debug--on-eve= nt] 6 >> >> (fn SYMBOL NEWVAL OPERATION WHERE)]) >> >> I don't think ordinary Emacs users can read byte-code objects. I >> certainly cannot. > > It's not optimal, indeed. See a somewhat better arrangement we have > with the variables which should trigger redisplay of the current > buffer, at the end of frame.el. I've tried this: diff --git a/lisp/help-fns.el b/lisp/help-fns.el index 9324cf85454..f4f595aedbe 100644 --- a/lisp/help-fns.el +++ b/lisp/help-fns.el @@ -1712,7 +1712,9 @@ help-fns--var-watchpoints (when watchpoints (princ " Calls these functions when changed: ") ;; FIXME: Turn function names into hyperlinks. - (princ watchpoints) + (dolist (watchpoint watchpoints) + (princ (help-fns-function-name watchpoint)) + (princ "\n ")) (terpri)))) =20 it generates a three-digit hex hash of the function, which is a lot nicer than bytecode, but still not ideal. Adding a docstring and a name to the function produces: Calls these functions when changed: (#[1028 \300!\207 [debug--on-event] 6= (bindings.elc . 52251)]) If there's a better way to fix this minor problem, we probably should. >> Should we fix that in the documentation code, work around it by naming >> the watcher, or both? > > See above: changing the way we call the watcher is probably easier, > and yields satisfactory results. Here's the current patch. It doesn't feel quite right yet, but I can't tell why right now: diff --git a/lisp/bindings.el b/lisp/bindings.el index 9987f28c027..bd02aefa348 100644 --- a/lisp/bindings.el +++ b/lisp/bindings.el @@ -1642,7 +1642,13 @@ ctl-x-4-map (define-key ctl-x-4-map "c" 'clone-indirect-buffer-other-window) =20 ;; Signal handlers +(add-variable-watcher 'debug-on-event + (lambda (_symbol newval _operation _where) + (debug--on-event newval))) + (define-key special-event-map [sigusr1] 'ignore) +;; SIGUSR2, by default, invokes the debugger directly, so this binding +;; is ignored. (define-key special-event-map [sigusr2] 'ignore) =20 ;; Text conversion diff --git a/lisp/cus-start.el b/lisp/cus-start.el index 0f7d7c3c020..cdf777f6c9a 100644 --- a/lisp/cus-start.el +++ b/lisp/cus-start.el @@ -388,11 +388,6 @@ minibuffer-prompt-properties--setter =09=09=09=09=09 (const :tag "only shift-selection or mouse-drag" only) =09=09=09=09=09 (const :tag "off" nil)) =09=09=09=09 "24.1") - (debug-on-event debug - (choice (const :tag "None" nil) - (const :tag "When sent SIGUSR1" sigus= r1) - (const :tag "When sent SIGUSR2" sigus= r2)) - "24.1") (translate-upper-case-key-bindings keyboard boolean "29.1") ;; This is not good news because it will use the wrong ;; version-specific directories when you upgrade. We need diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el index 0ca3a0f931c..ea2d89ef2a2 100644 --- a/lisp/emacs-lisp/debug.el +++ b/lisp/emacs-lisp/debug.el @@ -860,6 +860,39 @@ 'cancel-debug-watch =20 (make-obsolete-variable 'debugger-previous-backtrace "no longer used." "29.1") + +;;;###autoload +(defun debug-on-event (event) + "Make EVENT enter the debugger. + +When Emacs receives the special event specified as the argument to this +function, it will try to break into the debugger as soon as possible +instead of processing the event normally through `special-event-map'. + +EVENT should be a symbol, either `sigusr1' or `sigusr2', or nil." + (setq debug-on-event event) + (debug--on-event event)) + +;;;###autoload +(defcustom debug-on-event 'sigusr2 + "Enter debugger on this event. +When Emacs receives the special event specified by this variable, +it will try to break into the debugger as soon as possible instead +of processing the event normally through `special-event-map'. + +Currently, the only supported values for this +variable are `sigusr1' and `sigusr2'." + :group 'debug + :type '(choice (const :tag "None" nil) + (const :tag "When sent SIGUSR1" sigusr1) + (const :tag "When sent SIGUSR2" sigusr2)) + :version "24.1") + +(make-obsolete-variable + 'debug-on-event + "use the function `debug-on-event' instead." + "31.0") + (defvar debugger-previous-backtrace nil) =20 (provide 'debug) diff --git a/src/keyboard.c b/src/keyboard.c index 6208b333e9c..d2043d669cf 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -8254,6 +8254,10 @@ deliver_input_available_signal (int sig) /* Signal number. */ int sig; =20 + /* True if this event is supposed to make us enter the debugger + instead of being treated as an input event. */ + bool debug_on_event; + /* Name of the signal. */ char *name; =20 @@ -8280,6 +8284,7 @@ add_user_signal (int sig, const char *name) p =3D xmalloc (sizeof *p); p->sig =3D sig; p->name =3D xstrdup (name); + p->debug_on_event =3D !strcmp (p->name, "sigusr2"); p->npending =3D 0; p->next =3D user_signals; user_signals =3D p; @@ -8288,42 +8293,56 @@ add_user_signal (int sig, const char *name) sigaction (sig, &action, 0); } =20 +DEFUN ("debug--on-event", Fdebug__on_event, Sdebug__on_event, 1, 1, 0, + doc: /* Internal function: use debug-on-event instead. */) + (Lisp_Object event) +{ + Lisp_Object ret =3D Qnil; + CHECK_SYMBOL (event); + + struct user_signal_info *p; + for (p =3D user_signals; p; p =3D p->next) + if (strcmp (SSDATA (SYMBOL_NAME (event)), p->name) =3D=3D 0) + { +=09p->debug_on_event =3D true; +=09ret =3D Qt; + } + else + p->debug_on_event =3D false; + + return ret; +} + static void handle_user_signal (int sig) { struct user_signal_info *p; - const char *special_event_name =3D NULL; - - if (SYMBOLP (Vdebug_on_event)) - special_event_name =3D SSDATA (SYMBOL_NAME (Vdebug_on_event)); =20 for (p =3D user_signals; p; p =3D p->next) if (p->sig =3D=3D sig) { - if (special_event_name -=09 && strcmp (special_event_name, p->name) =3D=3D 0) +=09if (p->debug_on_event) { /* Enter the debugger in many ways. */ debug_on_next_call =3D true; debug_on_quit =3D true; Vquit_flag =3D Qt; Vinhibit_quit =3D Qnil; - - /* Eat the event. */ - break; } - -=09p->npending++; -#if defined (USABLE_SIGIO) || defined (USABLE_SIGPOLL) -=09if (interrupt_input) -=09 handle_input_available_signal (sig); =09else -#endif =09 { -=09 /* Tell wait_reading_process_output that it needs to wake -=09 up and look around. */ -=09 if (input_available_clear_time) -=09 *input_available_clear_time =3D make_timespec (0, 0); +=09 p->npending++; +#if defined (USABLE_SIGIO) || defined (USABLE_SIGPOLL) +=09 if (interrupt_input) +=09 handle_input_available_signal (sig); +=09 else +#endif +=09 { +=09=09/* Tell wait_reading_process_output that it needs to wake +=09=09 up and look around. */ +=09=09if (input_available_clear_time) +=09=09 *input_available_clear_time =3D make_timespec (0, 0); +=09 } =09 } =09break; } @@ -13139,6 +13158,7 @@ syms_of_keyboard (void) defsubr (&Sevent_symbol_parse_modifiers); defsubr (&Sevent_convert_list); defsubr (&Sinternal_handle_focus_in); + defsubr (&Sdebug__on_event); defsubr (&Sread_key_sequence); defsubr (&Sread_key_sequence_vector); defsubr (&Srecursive_edit); @@ -13787,17 +13807,6 @@ syms_of_keyboard (void) Vselection_inhibit_update_commands =3D list2 (Qhandle_switch_frame, Qhandle_select_window); =20 - DEFVAR_LISP ("debug-on-event", - Vdebug_on_event, - doc: /* Enter debugger on this event. -When Emacs receives the special event specified by this variable, -it will try to break into the debugger as soon as possible instead -of processing the event normally through `special-event-map'. - -Currently, the only supported values for this -variable are `sigusr1' and `sigusr2'. */); - Vdebug_on_event =3D Qsigusr2; - DEFVAR_BOOL ("attempt-stack-overflow-recovery", attempt_stack_overflow_recovery, doc: /* If non-nil, attempt to recover from C stack overflo= ws. Thanks for the comments! I hope I didn't run off and do something totally different from what you intended. Pip From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 10:04:53 2025 Received: (at 75632) by debbugs.gnu.org; 22 Jan 2025 15:04:53 +0000 Received: from localhost ([127.0.0.1]:35807 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tacHk-0007AA-E8 for submit@debbugs.gnu.org; Wed, 22 Jan 2025 10:04:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47500) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tacHf-00079m-KJ for 75632@debbugs.gnu.org; Wed, 22 Jan 2025 10:04:49 -0500 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 1tacHJ-0001V7-5u; Wed, 22 Jan 2025 10:04:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=YmiBW4rd9x3uyYJ1M1IaagaPoG50P8c3KP9biDVKxa8=; b=NAWtJO7drDHr tOmWS4bLdlkxyQ8pD/bsbqIOhfoiWcfrvWuY6LC62SzjOoyDXtaSlW9JrhtMHeSUTtFmCIL4oxAqc 5DzydqYo7NdJ4WgRjMiAQ6CzlpV4f2w8Xl0sx+IbNDlClg34m7OSKyuZ8iktRuOYTokhsSVhtGsIz Brj2beXghHFwSGmM0SQxCtH0iUjrcSZkJSGEnpkEW/KGsNutfsuzr2dY9/Ytfi/OH9hhFco+u/BmA 07VL2JFxWf51LUxL45R2Do8mvVyK8dEfCMJLrdNPZPVOYPNNZUiFp/GO7AR/snkkLyuSLIKg7awgt ldYjZtpoWJbFSZDeOFUoYA==; Date: Wed, 22 Jan 2025 17:04:17 +0200 Message-Id: <86msfi3n66.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87tt9rc9oz.fsf@protonmail.com> (message from Pip Cet on Wed, 22 Jan 2025 12:30:45 +0000) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <877c6rc30l.fsf@protonmail.com> <861pwzanav.fsf@gnu.org> <87sepfam9u.fsf@protonmail.com> <86v7ub8iqx.fsf@gnu.org> <87ldv72l5l.fsf@protonmail.com> <868qr784w6.fsf@gnu.org> <87sepf0vt2.fsf@protonmail.com> <86plki7w8c.fsf@gnu.org> <87tt9rc9oz.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: yantar92@posteo.net, 75632@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: Wed, 22 Jan 2025 12:30:45 +0000 > From: Pip Cet > Cc: 75632@debbugs.gnu.org, yantar92@posteo.net > > "Eli Zaretskii" writes: > > >> Date: Sun, 19 Jan 2025 13:37:18 +0000 > >> From: Pip Cet > >> Cc: 75632@debbugs.gnu.org, yantar92@posteo.net > >> > >> "Eli Zaretskii" writes: > >> > >> > and at temacs time? > >> > >> I don't think it's a realistic scenario that someone needs to debug > >> non-interactive temacs, cannot use the default signal, and wants to > >> change it. > > > > I meant the interactive temacs, which begins by loading all the > > preloaded packages. So one of those could add the watcher. > > Do we really need this to be added early? Only if we care about sending SIGUSR2 before bindings.el is loaded. I guess we can leave it in bindings.el, and wait for someone to complain that it doesn't work earlier. > > One of the first files we load in loadup, I think? Like subr.el, > > perhaps? > > See above. I think if you need to put an --eval '(debug--on-event > (quote sigusr1))' in your temacs invocation, you're likely knowledgeable > enough to do so. Does it really help? I think temacs loads the preloaded files before it processes --eval on the command line, isn't that so? > The only case that's really different is temacs -nl: it would probably > behave differently if it worked (to the extend bare temacs even does). Not sure "temacs -nl" is important in this context. I've never used that except for debugging very rare and special problems. > temacs -nl fixable, but I'll wait for a response before looking into > doing that properly. Might not be worth it. I wouldn't complicate the code because of "temacs -nl". > > It's not optimal, indeed. See a somewhat better arrangement we have > > with the variables which should trigger redisplay of the current > > buffer, at the end of frame.el. > > I've tried this: > > diff --git a/lisp/help-fns.el b/lisp/help-fns.el > index 9324cf85454..f4f595aedbe 100644 > --- a/lisp/help-fns.el > +++ b/lisp/help-fns.el > @@ -1712,7 +1712,9 @@ help-fns--var-watchpoints > (when watchpoints > (princ " Calls these functions when changed: ") > ;; FIXME: Turn function names into hyperlinks. > - (princ watchpoints) > + (dolist (watchpoint watchpoints) > + (princ (help-fns-function-name watchpoint)) > + (princ "\n ")) > (terpri)))) > > it generates a three-digit hex hash of the function, which is a lot > nicer than bytecode, but still not ideal. > > Adding a docstring and a name to the function produces: > > Calls these functions when changed: (#[1028 \300!\207 [debug--on-event] 6 (bindings.elc . 52251)]) > > If there's a better way to fix this minor problem, we probably should. This might be a misunderstanding. I meant to use a subr, as we do in frame.el. "C-h v" then says: Calls these functions when changed: (#) Isn't that slightly nicer than (#[1028 \300!\207 [debug--on-event] 6 (bindings.elc . 52251)]) ? That would mean make debug--on-event a subr, not a DEFUN. > @@ -8280,6 +8284,7 @@ add_user_signal (int sig, const char *name) > p = xmalloc (sizeof *p); > p->sig = sig; > p->name = xstrdup (name); > + p->debug_on_event = !strcmp (p->name, "sigusr2"); Hmm... why only sigusr2? what about sigusr1? > I hope I didn't run off and do something totally different from what > you intended. Doesn't look like that, no. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 10:55:20 2025 Received: (at 75632) by debbugs.gnu.org; 22 Jan 2025 15:55:20 +0000 Received: from localhost ([127.0.0.1]:35995 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tad4Z-0001Sq-Cl for submit@debbugs.gnu.org; Wed, 22 Jan 2025 10:55:19 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]:15529) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tad4V-0001Rx-Om for 75632@debbugs.gnu.org; Wed, 22 Jan 2025 10:55:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737561308; x=1737820508; bh=WTFAykroFtRh/zeBQG1I+J8d7lTUPpdONDfnW0EUTqo=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=Itsiex9e7N8olYEk8fcHiYflzUmMKB30RX6AoDZ5Fw90HxRSNMmlL0vC4PJZVF98Q DdOv9JaiOzaz1MWZlP4Hof4Kj66mgoDq/22fmJRH1ZdwqdKgTuHGG34zSyhhRJmDVz 8rQKjyUa0a0iJslsvs04hK9XTBIQH7O/3GMss2lEnsM9sMud8gatLcGeCsMiTAeISO 1dV4LiQNbPWyz/HpGPab0MVmtDTaJbWRhtW7RtLEiqc4CRVEHizbbwwUbFxgUlUL2y 4qlr83cRgUYm1qrsmz1FdweCy+rJMp5+jPK/bSTzeuK8HpWLscgm8MnFT+Xtu4vjf1 qHmsxuNDiqG0g== Date: Wed, 22 Jan 2025 15:55:05 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <871pwudesv.fsf@protonmail.com> In-Reply-To: <86msfi3n66.fsf@gnu.org> References: <87a5bpo6bv.fsf@localhost> <87sepfam9u.fsf@protonmail.com> <86v7ub8iqx.fsf@gnu.org> <87ldv72l5l.fsf@protonmail.com> <868qr784w6.fsf@gnu.org> <87sepf0vt2.fsf@protonmail.com> <86plki7w8c.fsf@gnu.org> <87tt9rc9oz.fsf@protonmail.com> <86msfi3n66.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 1e8919bca1542b8c686be9a3d8562c005243d7c2 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: 75632 Cc: yantar92@posteo.net, 75632@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: Wed, 22 Jan 2025 12:30:45 +0000 >> From: Pip Cet >> Cc: 75632@debbugs.gnu.org, yantar92@posteo.net >> >> "Eli Zaretskii" writes: >> >> >> Date: Sun, 19 Jan 2025 13:37:18 +0000 >> >> From: Pip Cet >> >> Cc: 75632@debbugs.gnu.org, yantar92@posteo.net >> >> >> >> "Eli Zaretskii" writes: >> >> >> >> > and at temacs time? >> >> >> >> I don't think it's a realistic scenario that someone needs to debug >> >> non-interactive temacs, cannot use the default signal, and wants to >> >> change it. >> > >> > I meant the interactive temacs, which begins by loading all the >> > preloaded packages. So one of those could add the watcher. >> >> Do we really need this to be added early? > > Only if we care about sending SIGUSR2 before bindings.el is loaded. > > I guess we can leave it in bindings.el, and wait for someone to > complain that it doesn't work earlier. I'm not sure I understand: you're thinking someone might modify one of the dozen or so Lisp files that are loaded before, in the Emacs tree, to attempt to set an obsolete variable to allow entering the debugger, which would also require changing things around so the debugger could even be loaded at that point? I'm confident that we'd have to wait for some time. >> > One of the first files we load in loadup, I think? Like subr.el, >> > perhaps? >> >> See above. I think if you need to put an --eval '(debug--on-event >> (quote sigusr1))' in your temacs invocation, you're likely knowledgeable >> enough to do so. > > Does it really help? I think temacs loads the preloaded files before > it processes --eval on the command line, isn't that so? You're right, but it turns out SIGUSR2 doesn't do anything noticeable with or without the patch, so SIGUSR1 can't, either. >> > It's not optimal, indeed. See a somewhat better arrangement we have >> > with the variables which should trigger redisplay of the current >> > buffer, at the end of frame.el. >> >> I've tried this: >> >> diff --git a/lisp/help-fns.el b/lisp/help-fns.el >> index 9324cf85454..f4f595aedbe 100644 >> --- a/lisp/help-fns.el >> +++ b/lisp/help-fns.el >> @@ -1712,7 +1712,9 @@ help-fns--var-watchpoints >> (when watchpoints >> (princ " Calls these functions when changed: ") >> ;; FIXME: Turn function names into hyperlinks. >> - (princ watchpoints) >> + (dolist (watchpoint watchpoints) >> + (princ (help-fns-function-name watchpoint)) >> + (princ "\n ")) >> (terpri)))) >> >> it generates a three-digit hex hash of the function, which is a lot >> nicer than bytecode, but still not ideal. >> >> Adding a docstring and a name to the function produces: >> >> Calls these functions when changed: (#[1028 \300!\207 [debug--on-event= ] 6 (bindings.elc . 52251)]) >> >> If there's a better way to fix this minor problem, we probably should. > > This might be a misunderstanding. I meant to use a subr, as we do in > frame.el. "C-h v" then says: You said: > Can we add the watcher in Lisp instead? Are there any reasons to have > it in C and at temacs time? I realize now that you can read the first sentence two ways, but the second one seems clear to me: there are no reasons to have the watcher in C. But as that patch had the defun in C, we can switch back to it. > Calls these functions when changed: (#) > > Isn't that slightly nicer than > > (#[1028 \300!\207 [debug--on-event] 6 (bindings.elc . 52251)]) > > ? That would mean make debug--on-event a subr, not a DEFUN. Let's add the symbol, not the function cell, and everything will be fine. We still need to fix the output of C-h v when watchers are in effect, but that's a separate issue. However, I also don't understand how a subr, which is defined by DEFUN, is different from "a DEFUN". Did you mean to write "defun"? >> @@ -8280,6 +8284,7 @@ add_user_signal (int sig, const char *name) >> p =3D xmalloc (sizeof *p); >> p->sig =3D sig; >> p->name =3D xstrdup (name); >> + p->debug_on_event =3D !strcmp (p->name, "sigusr2"); > > Hmm... why only sigusr2? what about sigusr1? The default behavior is for sigusr2 to enter the debugger and for sigusr1 to execute its binding, which is 'ignore. Changing SIGUSR1 to also enter the debugger by default would be a breaking change and require significant documentation adjustments. (Also, why?) Pip From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 11:12:51 2025 Received: (at 75632) by debbugs.gnu.org; 22 Jan 2025 16:12:51 +0000 Received: from localhost ([127.0.0.1]:36051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tadLW-0002IN-RP for submit@debbugs.gnu.org; Wed, 22 Jan 2025 11:12:51 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59600) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tadLT-0002I0-4m for 75632@debbugs.gnu.org; Wed, 22 Jan 2025 11:12:48 -0500 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 1tadLN-0006ss-Lw; Wed, 22 Jan 2025 11:12:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ibPaj4ETj54fDqIT0OnGg5Dl491QVzZn9vCnIWmycl0=; b=LnwAutTDZALH bfNccLnDisXc3gfY7yZn4HvsiCCQTX53hWgBKYGKeGmDOJPM2kNL777K+OEfL692Pnhr0G2xmS9pE roL0xoY/a2hD1u10Ly0FXtFtj8gLF9yGthlplHbY/+AfmBPDC01728TGRQ27go1o11+lJGPinngwW WcnqT5L7iouTHjVGLcIZHMbJFnhn+bnHwgvfsYZ/hbuJfPAKwwzu8j5lvECy6Kiju1PTkrV+lLy/F sGG9CgQ6FMRVeSdCsB7qOhxh10xb5XqgS64AbkW7xaaxrGA245GJcz8q+uCzSAYYfGUN4mbOy/RoE ifYfwC7uNeKs79rC6pBknw==; Date: Wed, 22 Jan 2025 18:12:37 +0200 Message-Id: <86frla3k0a.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <871pwudesv.fsf@protonmail.com> (message from Pip Cet on Wed, 22 Jan 2025 15:55:05 +0000) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <87sepfam9u.fsf@protonmail.com> <86v7ub8iqx.fsf@gnu.org> <87ldv72l5l.fsf@protonmail.com> <868qr784w6.fsf@gnu.org> <87sepf0vt2.fsf@protonmail.com> <86plki7w8c.fsf@gnu.org> <87tt9rc9oz.fsf@protonmail.com> <86msfi3n66.fsf@gnu.org> <871pwudesv.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: yantar92@posteo.net, 75632@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: Wed, 22 Jan 2025 15:55:05 +0000 > From: Pip Cet > Cc: 75632@debbugs.gnu.org, yantar92@posteo.net > > However, I also don't understand how a subr, which is defined by DEFUN, > is different from "a DEFUN". Did you mean to write "defun"? I guess so. > >> @@ -8280,6 +8284,7 @@ add_user_signal (int sig, const char *name) > >> p = xmalloc (sizeof *p); > >> p->sig = sig; > >> p->name = xstrdup (name); > >> + p->debug_on_event = !strcmp (p->name, "sigusr2"); > > > > Hmm... why only sigusr2? what about sigusr1? > > The default behavior is for sigusr2 to enter the debugger and for > sigusr1 to execute its binding, which is 'ignore. Changing SIGUSR1 to > also enter the debugger by default would be a breaking change and > require significant documentation adjustments. (Also, why?) I guess I was confused and thought that both SIGUSR1 and SIGUSR2 were supposed to start the debugger. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 24 22:05:45 2025 Received: (at 75632) by debbugs.gnu.org; 25 Jan 2025 03:05:45 +0000 Received: from localhost ([127.0.0.1]:47955 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tbWUT-0001aY-7f for submit@debbugs.gnu.org; Fri, 24 Jan 2025 22:05:45 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50108) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tbWUQ-0001aI-6j for 75632@debbugs.gnu.org; Fri, 24 Jan 2025 22:05:43 -0500 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 1tbWUJ-0006ik-K1; Fri, 24 Jan 2025 22:05:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=U9kiddBbfm+ghB6HajGVT/9L3W+18zjQvbGcSrLNLGU=; b=qB807VwjnPRv mNDXVxO+kn86D8dW/HQxU6BjdKVXwrbfiUNLmPtQ4DfeRaTCWe/MrN2mN70UJmlALRMM5zf0mq4Xs X5kPriDUmILdAXhPUoanFc41nh0FHZeCjdVqcZATbFwnBy6z8bWedI/Dhd2Z7IDA0uS6KS9FURt0s 9iZBNgfp8NzsYtBdRaRlbsef0xiUzUlkekCw7CxsQo8PPoOlxOZ5KVZnvY84XDTLx774fdmysVICf 41qb4xLdMICur9lX8mcBnav64+HOhci9hWhQqrdgw951SCw9c4P11MOSB97KFeNuuJug+OdHCsdZq 9vAHRLN/lolllnQmBFrHTg==; Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1tbWUF-0006C8-8I; Fri, 24 Jan 2025 22:05:32 -0500 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: Eli Zaretskii In-Reply-To: <86frla3k0a.fsf@gnu.org> (message from Eli Zaretskii on Wed, 22 Jan 2025 18:12:37 +0200) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <87sepfam9u.fsf@protonmail.com> <86v7ub8iqx.fsf@gnu.org> <87ldv72l5l.fsf@protonmail.com> <868qr784w6.fsf@gnu.org> <87sepf0vt2.fsf@protonmail.com> <86plki7w8c.fsf@gnu.org> <87tt9rc9oz.fsf@protonmail.com> <86msfi3n66.fsf@gnu.org> <871pwudesv.fsf@protonmail.com> <86frla3k0a.fsf@gnu.org> Message-Id: Date: Fri, 24 Jan 2025 22:05:31 -0500 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: pipcet@protonmail.com, yantar92@posteo.net, 75632@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: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > I guess I was confused and thought that both SIGUSR1 and SIGUSR2 were > supposed to start the debugger. Could people make sure that the documentation is up to date about this point in all the places it is described? -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 25 04:31:23 2025 Received: (at 75632) by debbugs.gnu.org; 25 Jan 2025 09:31:23 +0000 Received: from localhost ([127.0.0.1]:48518 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tbcVe-0001DD-4T for submit@debbugs.gnu.org; Sat, 25 Jan 2025 04:31:23 -0500 Received: from mail-40134.protonmail.ch ([185.70.40.134]:15733) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tbcVa-0000wN-TI for 75632@debbugs.gnu.org; Sat, 25 Jan 2025 04:31:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737797472; x=1738056672; bh=8hEepjZGKYMmb97V0qrFA/yhIX25/Iu4V0Mx/0bb/d8=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=DnlJ234jq9PtmmeNQJczgNUEZV2xyDUxYZnSOekilMpuCyKefXrItoKBOP/whAC1y SeHpWUHRN2oO1TTTClgwR5M2ePT5ty6VpnYxqEJhQ7SxAQn2EoCnYB+Ng+PTfHUILY ew/nQoR9M3KnhnXEaVQezCU47NiKdYjfVckOSgF8fvXkheIWKpJMvp2WeUxSU3XQYF Jo55Z2+5N1YMkHJfopfIQWyND9wHL91UpKleNoPWgE7a0pcl0Lhhi+/bSVz02WyWD7 EDQeWUz03IYtEhI0HlY+x6Pml5TvUiq7JZxE6Zn110ZZOAH3UCWv3aAu03rkn867Dv gm4KH7LLr4naw== Date: Sat, 25 Jan 2025 09:31:05 +0000 To: Richard Stallman From: Pip Cet Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <87tt9ntf3o.fsf@protonmail.com> In-Reply-To: References: <87a5bpo6bv.fsf@localhost> <868qr784w6.fsf@gnu.org> <87sepf0vt2.fsf@protonmail.com> <86plki7w8c.fsf@gnu.org> <87tt9rc9oz.fsf@protonmail.com> <86msfi3n66.fsf@gnu.org> <871pwudesv.fsf@protonmail.com> <86frla3k0a.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: abfd49ff9d2b3fdd79bba55ee18d21a7b87daa66 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: 75632 Cc: Eli Zaretskii , yantar92@posteo.net, 75632@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 (-) "Richard Stallman" writes: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > I guess I was confused and thought that both SIGUSR1 and SIGUSR2 were > > supposed to start the debugger. > > Could people make sure that the documentation is up to date about this > point in all the places it is described? It currently isn't; the section on sigusr1/sigusr2 in commands.texi doesn't mention debug-on-event, and the section on debug-on-event in debugging.texi doesn't mention its default value. That means anyone attempting to bind sigusr2 as a key will be in for a big surprise, because the curent behavior is to enter the debugger by default. This diff may explain better than a long list what I'd like to change about the documentation, even if the wording is bad. It is very rare to need to alter or call (after the patch) the debug-on-error variable/function. Setting it to nil may be useful in exceptional situations, but I don't actually see the need for using SIGUSR1 at this time. My impression was that this was originally meant to be expanded to more signals (that would be useful, as some other programs generate specific events and it's hard to modify them), but that never happened. Even if the sentence about signals not carrying additional information were accurate (on GNU/Linux, it simply isn't), I don't see the relevance to this section at all, so I removed it. Again, the wording can and should be improved, but the old docs are inaccurate and the new ones, I hope, less so. Pip diff --git a/doc/lispref/commands.texi b/doc/lispref/commands.texi index 39514145a1e..9ccc07a3291 100644 --- a/doc/lispref/commands.texi +++ b/doc/lispref/commands.texi @@ -2731,16 +2731,20 @@ Misc Events @cindex user signals @item sigusr1 @itemx sigusr2 -These events are generated when the Emacs process receives -the signals @code{SIGUSR1} and @code{SIGUSR2}. They contain no -additional data because signals do not carry additional information. -They can be useful for debugging (@pxref{Error Debugging}). - -To catch a user signal, bind the corresponding event to an interactive -command in the @code{special-event-map} (@pxref{Controlling Active Maps}). -The command is called with no arguments, and the specific signal event is -available in @code{last-input-event} (@pxref{Event Input Misc}. For -example: +When the Emacs process receives @code{SIGUSR1}, the @code{sigusr1} event +is generated and treated as an input event. This event contains no +additional data. This can be useful for debugging (@pxref{Error +Debugging}). + +It is possible to modify @code{debug-on-event} to do the same when +@code{SIGUSR2} is received instead, or for both events. By default, +binding @code{sigusr2} has no effect. + +To catch a user signal which is not used by @code{debug-on-event}, bind +the corresponding event to an interactive command in the +@code{special-event-map} (@pxref{Controlling Active Maps}). The command +is called with no arguments, and the specific signal event is available +in @code{last-input-event} (@pxref{Event Input Misc}. For example: =20 @smallexample (defun sigusr-handler () diff --git a/doc/lispref/debugging.texi b/doc/lispref/debugging.texi index 9b36f9ecdb2..d9b12137b4b 100644 --- a/doc/lispref/debugging.texi +++ b/doc/lispref/debugging.texi @@ -112,6 +112,14 @@ Error Debugging defined in this subsection to debug errors in Lisp that the redisplay code has invoked. @xref{Debugging Redisplay}, for help with these. =20 +One way to invoke the debugger even in extreme situations is to send +Emacs a @code{SIGUSR2} signal. This will make Emacs try to enter the +debugger as soon as possible after the signal. There is a small risk +this results in unexpected or erroneous behavior. + +In this case, @code{special-event-map} or other bindings are not +consulted. + @defopt debug-on-error This variable determines whether the debugger is called when an error is signaled and not handled. If @code{debug-on-error} is @code{t}, @@ -187,12 +195,13 @@ Error Debugging @end defopt =20 @defopt debug-on-event -If you set @code{debug-on-event} to a special event (@pxref{Special -Events}), Emacs will try to enter the debugger as soon as it receives -this event, bypassing @code{special-event-map}. At present, the only -supported values correspond to the signals @code{SIGUSR1} and -@code{SIGUSR2} (this is the default). This can be helpful when -@code{inhibit-quit} is set and Emacs is not otherwise responding. +You can change which signals enter the debugger by setting +@code{debug-on-event} to an event name; the default is @code{sigusr2}. +This can be helpful when @code{inhibit-quit} is set and +Emacs is not otherwise responding. + +At present, the only other supported values are @code{sigusr1}, to use +@code{SIGUSR1} instead, and @code{nil}, disabling the feature entirely. @end defopt =20 @cindex message, finding what causes a particular message From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 26 13:17:49 2025 Received: (at 75632) by debbugs.gnu.org; 26 Jan 2025 18:17:49 +0000 Received: from localhost ([127.0.0.1]:57819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tc7Cf-0004J5-6U for submit@debbugs.gnu.org; Sun, 26 Jan 2025 13:17:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41888) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tc7Cb-0004Ii-Hm for 75632@debbugs.gnu.org; Sun, 26 Jan 2025 13:17:46 -0500 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 1tc7CW-0004K7-48; Sun, 26 Jan 2025 13:17:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=DZBChIBeweNFbkxpgfzVobk9kSwqVHtm2elB8C22y2s=; b=Ydedz96lFrpp scGSQQr0q9CzjcE0h/9VUCCkRkgYO+IIM9V5s1K5bJwqK58cWDRhUsci2ONX40PmzeXiefSOSRVTH 6VV18nJaO7jSIzcdTf8GOqgqAjzRduJGaGmWAUIKIIQCbLrFEYlit0fyLUtH+hRThA9QpOq7YuwCc +JiyFNXu6OHtgXj48TXVO780/QPJYAf028emBffq0TGu2trFhZzExltIvq9zNlV2f6jXdnaq+vqO0 qP1CoZqHAjCPGTzHU7RXM+HHXpDfewS8dIB5aojFeEkXOI7SmIJx4AwMx2Tz1d6oHRoOv+1ySd0Ng C54TVoLPmCQOJYbsLsWlSA==; Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1tc7CV-0002yP-GN; Sun, 26 Jan 2025 13:17:39 -0500 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: Pip Cet In-Reply-To: <87tt9ntf3o.fsf@protonmail.com> (bug-gnu-emacs@gnu.org) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <868qr784w6.fsf@gnu.org> <87sepf0vt2.fsf@protonmail.com> <86plki7w8c.fsf@gnu.org> <87tt9rc9oz.fsf@protonmail.com> <86msfi3n66.fsf@gnu.org> <871pwudesv.fsf@protonmail.com> <86frla3k0a.fsf@gnu.org> <87tt9ntf3o.fsf@protonmail.com> Message-Id: Date: Sun, 26 Jan 2025 13:17:39 -0500 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: eliz@gnu.org, yantar92@posteo.net, 75632@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: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > This diff may explain better than a long list what I'd like to change > about the documentation, even if the wording is bad. Thanks for getting this started. I expect that the other people here will help fix any little details and get this installed. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From unknown Fri Jun 20 07:26:34 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 24 Feb 2025 12:24:10 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator