From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Oct 2024 10:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 73838@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.17290756697568 (code B ref -1); Wed, 16 Oct 2024 10:48:02 +0000 Received: (at submit) by debbugs.gnu.org; 16 Oct 2024 10:47:49 +0000 Received: from localhost ([127.0.0.1]:58715 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t11ZF-0001xy-DU for submit@debbugs.gnu.org; Wed, 16 Oct 2024 06:47:49 -0400 Received: from lists.gnu.org ([209.51.188.17]:49988) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t11ZB-0001xm-Kd for submit@debbugs.gnu.org; Wed, 16 Oct 2024 06:47:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t11Yo-0003Cd-Kz for bug-gnu-emacs@gnu.org; Wed, 16 Oct 2024 06:47:22 -0400 Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t11Ym-0006fG-FD for bug-gnu-emacs@gnu.org; Wed, 16 Oct 2024 06:47:22 -0400 Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-5c95a962c2bso5565046a12.2 for ; Wed, 16 Oct 2024 03:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729075638; x=1729680438; darn=gnu.org; h=mime-version:message-id:date:subject:to:from:from:to:cc:subject :date:message-id:reply-to; bh=aThivxToF9CFzG4HDgk7anrLr6npQ7MKfES6girQWZo=; b=TYyJIFec0Xy4VQF1oNkhFu49q+jEu9hoz+3s/Z+MmBJ76zDONnvRdWZz/OKk2W/Swj ikq2+X73meqYj7C/dRNNZmgnK/gdqa3abVqkDEnrCH30588XEU4H+wASMRQRVI18oakd dVpH4uZ6D6rqoAmf+l012ES8tGaTHTpdXdk1QOjdM2y1jkGeUG3a8s7bnaBdgg75R6ZC o9lZc5pq9QZXXk5hs5ByU9aeQR87aD9V78TYmlCknv73nYLg9hl/uMWWv63h8kvwugzJ jvEZIA/Hi0ssU6S/Pk/Ut0H51bXGWJut4WOAINTB2xDa9cG+evE3rtafsk9IP/4GU/AD RuRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729075638; x=1729680438; h=mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=aThivxToF9CFzG4HDgk7anrLr6npQ7MKfES6girQWZo=; b=AB6bA0tFkWhymB9UZgINiUCpfL3SQNfl/xXqcy/gJe+p1a/0it0X0NAyqyRiJNd33u EhOttpoK2QqdhFrVLDhiBbB6IpfThBiBZSL+DVADdJscH5/8oSeZrtrhIySlNaJ4yLe+ eB94nusOxgJtS2cMOL6JulLC4a8gs3bFZruhyxafdZXd8gDSq6yqkJyUSdkC2SvqmtUD BRCFDYNYTCnFMRPqvpObxKRLdMEBKzrIIFXEcZy63j19vs96+JwDF0VWv8M5Cq+h8DME cxAR+ApJ/AbRZ6jTqVktEChEkpLs4qh8xO1eM6Vgn78d0EsKTWQARBiVZL2Z1tSM1fOE CoxA== X-Gm-Message-State: AOJu0Yw+UcOsQPVj+Yswc3FYzUz16//GCmNR00B6vZQreZxI0AR4LlBG yIn9Z55XnEKRv1V9LkHjO9PGqI8vsoYwhhZkGiPyJ62R0KMYBkUid4dvJw== X-Google-Smtp-Source: AGHT+IEH3K5oBgoNpLj5Z3ZphOG4WFxVQmH2zAvLTlBAwAjf3RgtyYQosFU4tttsvB7HHFZHgcpo3w== X-Received: by 2002:a05:6402:4347:b0:5c9:5665:8df5 with SMTP id 4fb4d7f45d1cf-5c95665905amr11568075a12.34.1729075637226; Wed, 16 Oct 2024 03:47:17 -0700 (PDT) Received: from pro2 (pd9e36c48.dip0.t-ipconnect.de. [217.227.108.72]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5c98d77995esm1589338a12.65.2024.10.16.03.47.14 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Oct 2024 03:47:15 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Date: Wed, 16 Oct 2024 12:47:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::532; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x532.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) 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.3 (--) This is with master fdac10b216f7b47e2eea129d2a96807a0c2055f3 on macOS, built with ASAN. $ /Users/gerd/emacs/savannah/master/configure --cache-file /var/folders/1d/k_6t25f94sl83szqbf8gpkrh0000gn/T//config.cache.master --without-tree-sitter --with-native-compilation=no CC=clang 'LDFLAGS=-fsanitize=address -fno-omit-frame-pointer' 'CFLAGS=-Wgnu-imaginary-constant -Wunused-result -g -fno-omit-frame-pointer -g -O0 -fsanitize=address -fno-omit-frame-pointer' Recipe: - emacs -nw -q - M-x xterm-mouse-mode RET - M-x make TAB - Move the move over the completion candidates => ASAN abort in note_mouse_highlight, xdisp.c:36108 The line number may vary. Looking at that in the debugger, I see default: /* This should not happen. */ if (cursor != FRAME_OUTPUT_DATA (f)->nontext_cursor) cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; nsterm.h defines FRAME_OUTPUT_DATA(f) as #define FRAME_OUTPUT_DATA(f) ((f)->output_data.ns) and since we are not in a GUI frame, this is no good. Analogous defines are in xterm.h etc., so the problem is not limited to macOS. (I built with ASAN because I observe weird things with mouse stuff in conjunction with tty child frames, and wanted to check what's up with that in master.) From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Oct 2024 14:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.172908847714762 (code B ref 73838); Wed, 16 Oct 2024 14:22:01 +0000 Received: (at 73838) by debbugs.gnu.org; 16 Oct 2024 14:21:17 +0000 Received: from localhost ([127.0.0.1]:60046 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t14tp-0003q1-8t for submit@debbugs.gnu.org; Wed, 16 Oct 2024 10:21:17 -0400 Received: from mail-wr1-f50.google.com ([209.85.221.50]:42343) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t14tn-0003pu-Jx for 73838@debbugs.gnu.org; Wed, 16 Oct 2024 10:21:16 -0400 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-37d41894a32so703984f8f.1 for <73838@debbugs.gnu.org>; Wed, 16 Oct 2024 07:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729088395; x=1729693195; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:to:from:from:to:cc:subject:date:message-id:reply-to; bh=mTJc6sjBqkAbsAX4dlL8XFtgC4wC3UCWiJmfOQyAMck=; b=LxTpDeafVK+h7dc7DBBu31F+wGzQq9YIyJf9IktURDVd+jy2NSsCFy4m5UhbclZyq5 4K8ganDUoYj06JEfvEgcGw9dmnCYoc+US9zd0IGWokBUQhbm19+CUkgbmKCPGKC+Jk6A NYtEDv6XagCrok6R5gN/Q/bt4Se+Q5FYU05i4GwwAisUXFTnOaXkl8c2MZr2tz3vEp4P 7u/EwL14AwswGHUXfUiBTmiNlJVydBAZJ2+0/8ejslfLekWMCBJaloM06dtcYwWHB0Yk HtRKnlWNvs+sj705QNHWw4d8tQWyApLSk4xtP8hRdQtRvrb5QdXeKstEuWcYlBfKWFxf ccXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729088395; x=1729693195; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mTJc6sjBqkAbsAX4dlL8XFtgC4wC3UCWiJmfOQyAMck=; b=JOrhfmCLYBrBcom50oA3sfL7KjJ+eywqc26SslTHsWXEeelVOl/n5Co7JIM41ZQNJl sLNrfKnJ2ZYPP58lo1t9nKSjMcXceH9/k/OnkQa5R7ttr2uUSzkXf7qomKMkb+p0yFLv LAx/i0iaKjWK3mTGcv7dTgk6JmDVtKNzgBYmLE1WepwBz9Ncj9TdZu1XCPaf3kwIdOGI SF4gHSBgbQ1GVy5pFycjpBkNdbILxI157KeZv18T+SBMc6sDnCPh49KnZHmCgObl1YfQ S2YLx1mz7plyoW/xJbTwcZ405NkiQ6qmC/agr4Gz9MXjS42UkuJuxXmsuHHpHrLrFUmD MlAg== X-Gm-Message-State: AOJu0Yy0nha3Q6XmyMEEwD4HyKUU9ptHnwZfthcvOusKfIfgB7XZRbB7 3dJ95HVzIFvAJtIlc6rWDb/BWjTWU/jtZ8Ekp6HpJQWs9iU5yBPZM5+cdA== X-Google-Smtp-Source: AGHT+IGOFZOo1SGPOveWkxVQfw33L5pQpt2XFeh60So90hayCzVjvHeZpK9Kj3fMdwpCbHdOHD8uxQ== X-Received: by 2002:a05:6000:dd2:b0:374:c21a:9dd4 with SMTP id ffacd0b85a97d-37d5529cb8dmr14241359f8f.20.1729088394521; Wed, 16 Oct 2024 07:19:54 -0700 (PDT) Received: from pro2 (pd9e36c48.dip0.t-ipconnect.de. [217.227.108.72]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-37d7fbf8143sm4499473f8f.70.2024.10.16.07.19.53 for <73838@debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Oct 2024 07:19:54 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: ("Gerd =?UTF-8?Q?M=C3=B6llmann?="'s message of "Wed, 16 Oct 2024 12:47:13 +0200") References: Date: Wed, 16 Oct 2024 16:19:53 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) 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 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Gerd M=C3=B6llmann writes: > This is with master fdac10b216f7b47e2eea129d2a96807a0c2055f3 on > macOS, built with ASAN. > > $ /Users/gerd/emacs/savannah/master/configure --cache-file /var/folders= /1d/k_6t25f94sl83szqbf8gpkrh0000gn/T//config.cache.master --without-tree-si= tter --with-native-compilation=3Dno CC=3Dclang 'LDFLAGS=3D-fsanitize=3Daddr= ess -fno-omit-frame-pointer' 'CFLAGS=3D-Wgnu-imaginary-constant -Wunused-re= sult -g -fno-omit-frame-pointer -g -O0 -fsanitize=3Daddress -fno-omit-frame= -pointer' > > Recipe: > > - emacs -nw -q > - M-x xterm-mouse-mode RET > - M-x make TAB > - Move the move over the completion candidates > > =3D> ASAN abort in note_mouse_highlight, xdisp.c:36108 > > The line number may vary. Looking at that in the debugger, I see > > default: > /* This should not happen. */ > if (cursor !=3D FRAME_OUTPUT_DATA (f)->nontext_cursor) > cursor =3D FRAME_OUTPUT_DATA (f)->nontext_cursor; > > nsterm.h defines FRAME_OUTPUT_DATA(f) as > > #define FRAME_OUTPUT_DATA(f) ((f)->output_data.ns) > > and since we are not in a GUI frame, this is no good. Analogous defines > are in xterm.h etc., so the problem is not limited to macOS. > > (I built with ASAN because I observe weird things with mouse stuff in > conjunction with tty child frames, and wanted to check what's up with > that in master.) I'd like to propose a change like in the attached patch (from my tty child frames branch). It fixes the case I mentioned above. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=frame_output_data.patch Content-Description: FRAME_OUTPUT_DATA diff --git a/src/nsterm.h b/src/nsterm.h index 256a233558e..0343064fe5b 100644 --- a/src/nsterm.h +++ b/src/nsterm.h @@ -1020,10 +1020,18 @@ #define KEY_NS_SHOW_PREFS ((1<<28)|(0<<16)|14) int unused; }; +INLINE struct ns_output * +frame_output_data (struct frame *f) +{ + eassert (FRAME_NS_P (f)); + return f->output_data.ns; +} + +/* xdisp.c checks for this macro being #defined. */ +#define FRAME_OUTPUT_DATA(f) frame_output_data (f) /* This gives the ns_display_info structure for the display F is on. */ #define FRAME_DISPLAY_INFO(f) ((f)->output_data.ns->display_info) -#define FRAME_OUTPUT_DATA(f) ((f)->output_data.ns) #define FRAME_NS_WINDOW(f) ((f)->output_data.ns->window_desc) #define FRAME_NATIVE_WINDOW(f) FRAME_NS_WINDOW (f) diff --git a/src/xdisp.c b/src/xdisp.c index 25184e8d186..8321702b760 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -36106,7 +36106,8 @@ note_mouse_highlight (struct frame *f, int x, int y) #ifdef HAVE_WINDOW_SYSTEM /* If the cursor is on the internal border of FRAME and FRAME's internal border is draggable, provide some visual feedback. */ - if (FRAME_INTERNAL_BORDER_WIDTH (f) > 0 + if (FRAME_WINDOW_P (f) + && FRAME_INTERNAL_BORDER_WIDTH (f) > 0 && !NILP (get_frame_param (f, Qdrag_internal_border))) { enum internal_border_part part = frame_internal_border_part (f, x, y); @@ -36170,7 +36171,8 @@ note_mouse_highlight (struct frame *f, int x, int y) buffer. */ if (EQ (window, f->menu_bar_window)) { - cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; + if (FRAME_WINDOW_P (f)) + cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; goto set_cursor; } #endif @@ -36181,10 +36183,13 @@ note_mouse_highlight (struct frame *f, int x, int y) if (EQ (window, f->tab_bar_window)) { note_tab_bar_highlight (f, x, y); - if (tab_bar__dragging_in_progress) - cursor = FRAME_OUTPUT_DATA (f)->hand_cursor; - else - cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; + if (FRAME_WINDOW_P (f)) + { + if (tab_bar__dragging_in_progress) + cursor = FRAME_OUTPUT_DATA (f)->hand_cursor; + else + cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; + } goto set_cursor; } else @@ -36203,7 +36208,8 @@ note_mouse_highlight (struct frame *f, int x, int y) if (EQ (window, f->tool_bar_window)) { note_tool_bar_highlight (f, x, y); - cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; + if (FRAME_WINDOW_P (f)) + cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; goto set_cursor; } #endif @@ -36217,7 +36223,8 @@ note_mouse_highlight (struct frame *f, int x, int y) #ifdef HAVE_WINDOW_SYSTEM if (part == ON_LEFT_MARGIN || part == ON_RIGHT_MARGIN) { - cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; + if (FRAME_WINDOW_P (f)) + cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; /* Show non-text cursor (Bug#16647). */ goto set_cursor; } @@ -36229,13 +36236,15 @@ note_mouse_highlight (struct frame *f, int x, int y) #ifdef HAVE_WINDOW_SYSTEM if (part == ON_VERTICAL_BORDER) { - cursor = FRAME_OUTPUT_DATA (f)->horizontal_drag_cursor; + if (FRAME_WINDOW_P (f)) + cursor = FRAME_OUTPUT_DATA (f)->horizontal_drag_cursor; help_echo_string = build_string ("drag-mouse-1: resize"); goto set_cursor; } else if (part == ON_RIGHT_DIVIDER) { - cursor = FRAME_OUTPUT_DATA (f)->horizontal_drag_cursor; + if (FRAME_WINDOW_P (f)) + cursor = FRAME_OUTPUT_DATA (f)->horizontal_drag_cursor; help_echo_string = build_string ("drag-mouse-1: resize"); goto set_cursor; } @@ -36244,7 +36253,8 @@ note_mouse_highlight (struct frame *f, int x, int y) || minibuf_level || NILP (Vresize_mini_windows)) { - cursor = FRAME_OUTPUT_DATA (f)->vertical_drag_cursor; + if (FRAME_WINDOW_P (f)) + cursor = FRAME_OUTPUT_DATA (f)->vertical_drag_cursor; help_echo_string = build_string ("drag-mouse-1: resize"); goto set_cursor; } @@ -36252,13 +36262,17 @@ note_mouse_highlight (struct frame *f, int x, int y) cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; else if (part == ON_LEFT_FRINGE || part == ON_RIGHT_FRINGE) { - cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; + if (FRAME_WINDOW_P (f)) + cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; note_fringe_highlight (f, window, x, y, part); } else if (part == ON_VERTICAL_SCROLL_BAR || part == ON_HORIZONTAL_SCROLL_BAR) - cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; - else + { + if (FRAME_WINDOW_P (f)) + cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; + } + else if (FRAME_WINDOW_P (f)) cursor = FRAME_OUTPUT_DATA (f)->text_cursor; #endif --=-=-=-- From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Oct 2024 15:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.172909262026935 (code B ref 73838); Wed, 16 Oct 2024 15:31:02 +0000 Received: (at 73838) by debbugs.gnu.org; 16 Oct 2024 15:30:20 +0000 Received: from localhost ([127.0.0.1]:60121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t15yd-00070M-KD for submit@debbugs.gnu.org; Wed, 16 Oct 2024 11:30:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41166) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t15ya-000708-P3 for 73838@debbugs.gnu.org; Wed, 16 Oct 2024 11:30:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t15w5-0000Rw-Id; Wed, 16 Oct 2024 11:27:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=HPkzJQvp7DA/5VPYVrPfxTaIreEC4tlwq5NOS0uD75Q=; b=ixMmmxGYnpsjx8cMZrte iwUmZN60cyrV0FaTpLeKHays2q/COaQ/b4L5M8IPtryhMAMTbI/EaPnbPyrmDufrY888a/eWCepdj Di0nFFOHiVWEjBR79s0ZywFbjiGzvrbhXqZ03AY9ibHPezVfdLRAjc0NOUgK1hDNEoH8ycJ7zx2+0 nQ1QtB8CqBbgc7jm+o7zaiNLrORUvnxknx2MTF1vb3uJLizgW4K738P85ArkanhZVBM4XDUVMqzIi BNnWmGvACKyMbC9aVxqoiIpiOQgBKxZYkjzjrqjoPIT5q8GSyqsYfSPk9mwPtDDDq2zIAQE9MUrFw rh3/GSR/Pk0CZg==; Date: Wed, 16 Oct 2024 18:27:39 +0300 Message-Id: <86seswoyok.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Gerd =?UTF-8?Q?M=C3=B6llmann?= on Wed, 16 Oct 2024 12:47:13 +0200) References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Date: Wed, 16 Oct 2024 12:47:13 +0200 > > This is with master fdac10b216f7b47e2eea129d2a96807a0c2055f3 on > macOS, built with ASAN. > > $ /Users/gerd/emacs/savannah/master/configure --cache-file /var/folders/1d/k_6t25f94sl83szqbf8gpkrh0000gn/T//config.cache.master --without-tree-sitter --with-native-compilation=no CC=clang 'LDFLAGS=-fsanitize=address -fno-omit-frame-pointer' 'CFLAGS=-Wgnu-imaginary-constant -Wunused-result -g -fno-omit-frame-pointer -g -O0 -fsanitize=address -fno-omit-frame-pointer' > > Recipe: > > - emacs -nw -q > - M-x xterm-mouse-mode RET > - M-x make TAB > - Move the move over the completion candidates > > => ASAN abort in note_mouse_highlight, xdisp.c:36108 > > The line number may vary. Looking at that in the debugger, I see > > default: > /* This should not happen. */ > if (cursor != FRAME_OUTPUT_DATA (f)->nontext_cursor) > cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; > > nsterm.h defines FRAME_OUTPUT_DATA(f) as > > #define FRAME_OUTPUT_DATA(f) ((f)->output_data.ns) > > and since we are not in a GUI frame, this is no good. Analogous defines > are in xterm.h etc., so the problem is not limited to macOS. How come you got to that code on a TTY frame, when the condition for it is if (FRAME_INTERNAL_BORDER_WIDTH (f) > 0 && !NILP (get_frame_param (f, Qdrag_internal_border))) FRAME_INTERNAL_BORDER_WIDTH is supposed to be zero on TTY frames. Why isn't it? From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Oct 2024 15:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.172909311728374 (code B ref 73838); Wed, 16 Oct 2024 15:39:02 +0000 Received: (at 73838) by debbugs.gnu.org; 16 Oct 2024 15:38:37 +0000 Received: from localhost ([127.0.0.1]:60136 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t166e-0007Na-VT for submit@debbugs.gnu.org; Wed, 16 Oct 2024 11:38:37 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38094) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t166d-0007NK-1l for 73838@debbugs.gnu.org; Wed, 16 Oct 2024 11:38:35 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t166E-0001dH-0V; Wed, 16 Oct 2024 11:38:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=WAwe8qKGdQn93+vgohS5Ddj8siBF1yDXtcQ20BtPIL0=; b=akAnhp9IOmxkHsos48hp LwGgZNyTZUZeA3T3c5cKGlF+65ZwBG0FEUVEpR8hkX0DRv1ZMc7WRfFPBpmIPP19pVPDCHW4gxbgK 49bsoxoq8PXPKxx09/ygQmjakZwwzlgs5FMbQ/md3imzkD5BB3NIACQiToTts0282EN8A5Cgufu6k cqtCClJ0Gr8JC+D91P6pZ+30U5GTwbUAzPq+ROlFm57cx9kjiCRoNQ3YRoJVlODr5Dt0DdW1o8vhr nRLj47bhW1ir84M5/UdA1IoTuV+onOK2wYP6vNKk4obMA02Cg0vCWOpjDc0zGTXM4UEEMCo3XCQ0C 2S0y/HZpbiephw==; Date: Wed, 16 Oct 2024 18:38:05 +0300 Message-Id: <86r08goy76.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Gerd =?UTF-8?Q?M=C3=B6llmann?= on Wed, 16 Oct 2024 16:19:53 +0200) References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Date: Wed, 16 Oct 2024 16:19:53 +0200 > > I'd like to propose a change like in the attached patch (from my tty > child frames branch). It fixes the case I mentioned above. I'd like to understand why these changes are needed. Could you please elaborate on each and every change? > if (EQ (window, f->menu_bar_window)) > { > - cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; > + if (FRAME_WINDOW_P (f)) > + cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; Can a TTY frame have a menu-bar window? AFAIK, a menu bar is just a frame glyph row on TTY frames, it is not a window. > if (EQ (window, f->tab_bar_window)) > { > note_tab_bar_highlight (f, x, y); > - if (tab_bar__dragging_in_progress) > - cursor = FRAME_OUTPUT_DATA (f)->hand_cursor; > - else > - cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; > + if (FRAME_WINDOW_P (f)) > + { > + if (tab_bar__dragging_in_progress) > + cursor = FRAME_OUTPUT_DATA (f)->hand_cursor; > + else > + cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; > + } Same question here about tab-bar window. > if (EQ (window, f->tool_bar_window)) > { > note_tool_bar_highlight (f, x, y); > - cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; > + if (FRAME_WINDOW_P (f)) > + cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; > goto set_cursor; Same question here about tool-bar window. > #ifdef HAVE_WINDOW_SYSTEM > if (part == ON_LEFT_MARGIN || part == ON_RIGHT_MARGIN) > { > - cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; > + if (FRAME_WINDOW_P (f)) > + cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; This part I could understand. > #ifdef HAVE_WINDOW_SYSTEM > if (part == ON_VERTICAL_BORDER) > { > - cursor = FRAME_OUTPUT_DATA (f)->horizontal_drag_cursor; > + if (FRAME_WINDOW_P (f)) > + cursor = FRAME_OUTPUT_DATA (f)->horizontal_drag_cursor; Do we have vertical borders on TTY frames? If yes, this is also understood. > else if (part == ON_RIGHT_DIVIDER) > { > - cursor = FRAME_OUTPUT_DATA (f)->horizontal_drag_cursor; > + if (FRAME_WINDOW_P (f)) > + cursor = FRAME_OUTPUT_DATA (f)->horizontal_drag_cursor; > help_echo_string = build_string ("drag-mouse-1: resize"); > goto set_cursor; Do we have right dividers on TTY frames? > @@ -36244,7 +36253,8 @@ note_mouse_highlight (struct frame *f, int x, int y) > || minibuf_level > || NILP (Vresize_mini_windows)) > { > - cursor = FRAME_OUTPUT_DATA (f)->vertical_drag_cursor; > + if (FRAME_WINDOW_P (f)) > + cursor = FRAME_OUTPUT_DATA (f)->vertical_drag_cursor; > help_echo_string = build_string ("drag-mouse-1: resize"); Same question about bottom dividers as above about right dividers. > else if (part == ON_LEFT_FRINGE || part == ON_RIGHT_FRINGE) > { > - cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; > + if (FRAME_WINDOW_P (f)) > + cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; How can fringes happen on a TTY frame? > else if (part == ON_VERTICAL_SCROLL_BAR > || part == ON_HORIZONTAL_SCROLL_BAR) > - cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; > - else > + { > + if (FRAME_WINDOW_P (f)) > + cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; > + } > + else if (FRAME_WINDOW_P (f)) > cursor = FRAME_OUTPUT_DATA (f)->text_cursor; > #endif How can scroll bars happen on TTY frames? From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Oct 2024 16:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.17290969726910 (code B ref 73838); Wed, 16 Oct 2024 16:43:02 +0000 Received: (at 73838) by debbugs.gnu.org; 16 Oct 2024 16:42:52 +0000 Received: from localhost ([127.0.0.1]:60222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t176q-0001nO-5m for submit@debbugs.gnu.org; Wed, 16 Oct 2024 12:42:52 -0400 Received: from mail-wm1-f53.google.com ([209.85.128.53]:45345) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t176n-0001nA-Jm for 73838@debbugs.gnu.org; Wed, 16 Oct 2024 12:42:50 -0400 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4311c285bc9so230135e9.3 for <73838@debbugs.gnu.org>; Wed, 16 Oct 2024 09:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729096884; x=1729701684; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=H0P3tyW/4bk6JGnPV5U6o6V5JhkWPTKZ1yZTdsn5akU=; b=YYyC3ZA4/iSb68XMqlPB1QuEAD2zfN6guGjqNrjfAXVx9HEWDbp4Q09jjUIzMTqrIQ r5yfFvFRwHqDU52pQvMk0KZV4RT3oIFbSOKzq7Cdwy+ndm0TWkCFhG2jMw2UoE5lrsny k1Y3vq5H9hx5G/gAVHmAbofZ97xw1yAZ0Ob46uSndASjGy7tNyY7L6QnE8EECZRsAtcA +wvCEBXP8yzahglIIT+syZuj3XNV5mGmbgm8Stf2uDhPSNLuqfAGXXEKkWgtkDHcqNiy jippYo/4nPGL8yX9JgQAZVq1YdNQ985qkrIZF6RvlVHRtNjzQ3SKUAPDv/Ub3XzFcRJ9 jmQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729096884; x=1729701684; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=H0P3tyW/4bk6JGnPV5U6o6V5JhkWPTKZ1yZTdsn5akU=; b=UZ4bDJV4VOkvt/LHf5hQaCBxq/WF4zHKjZ4C2FMmRpgpo+1i2tFswcCTR5lSlj+1TV GlYk1kUux2UrtJb0kdYd0ljVFhmqTb/UR1nS+yLZmQhQxMWbeokdPcn8Vgqp6qDVHRcQ W4m1xj7IWESMJ4xAgjyTAtzvr/QHisDdBYvNb3In4OqqxnBrhd4G0bal+TmlCv0TUy8j etpD/z2y/id9Otxk7Mbt843vN+70iPB4Ya/IiTd2qPtfRw0/Z1E4Q2hAAcW6I4WsufRz 4kKKvg9djr8muZyqr31FxvDzNVLi0BZjaST3aLcRPyTk6guDUcIKKognvHPTx+iDZZ4C ohXw== X-Gm-Message-State: AOJu0YweGA/BpQVPu17nAmakv0vDv9kUB8PRgDpDcPDKoTplZjaI6qOE 3A/QqI+na2I1TMhMeLz9UQxlvUR8ZEBFPGz8591TQZBHGBEbdfYvnlXwlg== X-Google-Smtp-Source: AGHT+IFOo5v0TDVaJX7KdnFO0eragJIGbiwk5jpM9/KFMceqWfw00upZVejPl9Y0RD2i6Z4l56EWQA== X-Received: by 2002:adf:fd8e:0:b0:374:c17a:55b5 with SMTP id ffacd0b85a97d-37d551b07e0mr12888811f8f.14.1729096883396; Wed, 16 Oct 2024 09:41:23 -0700 (PDT) Received: from pro2 (pd9e36c48.dip0.t-ipconnect.de. [217.227.108.72]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-37d7fc4038bsm4734142f8f.100.2024.10.16.09.41.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Oct 2024 09:41:23 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: <86seswoyok.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 16 Oct 2024 18:27:39 +0300") References: <86seswoyok.fsf@gnu.org> Date: Wed, 16 Oct 2024 18:41:22 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Date: Wed, 16 Oct 2024 12:47:13 +0200 >>=20 >> This is with master fdac10b216f7b47e2eea129d2a96807a0c2055f3 on >> macOS, built with ASAN. >>=20 >> $ /Users/gerd/emacs/savannah/master/configure --cache-file /var/folder= s/1d/k_6t25f94sl83szqbf8gpkrh0000gn/T//config.cache.master --without-tree-s= itter --with-native-compilation=3Dno CC=3Dclang 'LDFLAGS=3D-fsanitize=3Dadd= ress -fno-omit-frame-pointer' 'CFLAGS=3D-Wgnu-imaginary-constant -Wunused-r= esult -g -fno-omit-frame-pointer -g -O0 -fsanitize=3Daddress -fno-omit-fram= e-pointer' >>=20 >> Recipe: >>=20 >> - emacs -nw -q >> - M-x xterm-mouse-mode RET >> - M-x make TAB >> - Move the move over the completion candidates >>=20 >> =3D> ASAN abort in note_mouse_highlight, xdisp.c:36108 >>=20 >> The line number may vary. Looking at that in the debugger, I see >>=20 >> default: >> /* This should not happen. */ >> if (cursor !=3D FRAME_OUTPUT_DATA (f)->nontext_cursor) >> cursor =3D FRAME_OUTPUT_DATA (f)->nontext_cursor; >>=20 >> nsterm.h defines FRAME_OUTPUT_DATA(f) as >>=20 >> #define FRAME_OUTPUT_DATA(f) ((f)->output_data.ns) >>=20 >> and since we are not in a GUI frame, this is no good. Analogous defines >> are in xterm.h etc., so the problem is not limited to macOS. > > How come you got to that code on a TTY frame, when the condition for > it is > > if (FRAME_INTERNAL_BORDER_WIDTH (f) > 0 > && !NILP (get_frame_param (f, Qdrag_internal_border))) > > FRAME_INTERNAL_BORDER_WIDTH is supposed to be zero on TTY frames. Why > isn't it? I'm not sure but I meanwhile get the impression that ASAN on Xcode 16 doesn't report correct line numbers anymore. Probably the problem was somewhere else. From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Oct 2024 16:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.17290978989528 (code B ref 73838); Wed, 16 Oct 2024 16:59:02 +0000 Received: (at 73838) by debbugs.gnu.org; 16 Oct 2024 16:58:18 +0000 Received: from localhost ([127.0.0.1]:60258 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t17Ll-0002Tc-FA for submit@debbugs.gnu.org; Wed, 16 Oct 2024 12:58:17 -0400 Received: from mail-wm1-f52.google.com ([209.85.128.52]:60516) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t17Lj-0002TU-Fr for 73838@debbugs.gnu.org; Wed, 16 Oct 2024 12:58:16 -0400 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4314735bca2so600095e9.0 for <73838@debbugs.gnu.org>; Wed, 16 Oct 2024 09:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729097814; x=1729702614; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=VqRpE1v34ytnev/ho/LqLPJMg/oF8B8x4Q64cuNGMHU=; b=NDepV5rMky+5YyjongCV+jvo3RzS3lxcvbgcyxH5ucsTShJgO67F8e62EzwcmwAJS2 kFKbBUYXcxggrs93VRjnJuO3L3zjSVRhsBx3wDhXZJCm5+Z2wa5+VIgo/nRmDyDAE0Od DdpdaLJpv0K/LIE4BNQURUHWxFpIIoCfar++v3WD2kdL9TCkd+pMMgV/KXR1YYoOwnG7 AbeER+ICHa0w1oJDvYHudyFC/sE1DXhsj3bbQDcKJElFnah9YhxhAXODOXvbVBQ3otmc YCysYlQb0bqDuo/SkNnup1JeRAYO+hxTmrCGCCvyNW++Iu1TL+AulCmAeYofXxa5oNG0 2/Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729097814; x=1729702614; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=VqRpE1v34ytnev/ho/LqLPJMg/oF8B8x4Q64cuNGMHU=; b=oB4BgfyYyNJh6uOE3a+cywoFBGBONuwYjI914kqAGHPeu6ZpqlsQQIRO+kbYuEEdTK yqlOpj2Hwwm7z6NLVG5LSvhejOXSUMobDDPkExuF1JyrpdsFdwUGcgnFoKwADEKeAE+2 F8+0JG81n1OB1VHM3/aVQ4VbO4yA6WtoFeYcXJS/y+neHujv7qTrhrNHNaLjvITYx9Nm CiGvq0JcxiFgozFGmLwVomNNDpH+744e+yq6Ffu1rAEr7HMocJ5rPypzd3/5x6FLtqXl 80Tbtg3Ay1Mkhltje+CwcKFcuuSBpTq9QRcjx3wlN4kXtrTS2aNN47QA1rvFzJMAfvXY 21jg== X-Gm-Message-State: AOJu0Yyl9t35JVhSX6NeMIdijUd1vuJldMPt8YHNT4wNV7RviEaMPh2j 2I0a3OJQNxL5mGhhmQAauEMwOba0SPIXf9v5nnX1i+z4UFgjwhNAlsdb6g== X-Google-Smtp-Source: AGHT+IEn1Ghk2Fc9QPBoTJra2VdE8dKLTWYoeS+XcO80ZrHrPYX5TPkylh6yQvNf1rpALRCWyV6WZA== X-Received: by 2002:a5d:4dc7:0:b0:37d:3def:2a82 with SMTP id ffacd0b85a97d-37d86d50442mr3345897f8f.36.1729097814351; Wed, 16 Oct 2024 09:56:54 -0700 (PDT) Received: from pro2 (pd9e36c48.dip0.t-ipconnect.de. [217.227.108.72]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-37d7fa7a055sm4827365f8f.1.2024.10.16.09.56.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Oct 2024 09:56:54 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: <86r08goy76.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 16 Oct 2024 18:38:05 +0300") References: <86r08goy76.fsf@gnu.org> Date: Wed, 16 Oct 2024 18:56:53 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Date: Wed, 16 Oct 2024 16:19:53 +0200 >>=20 >> I'd like to propose a change like in the attached patch (from my tty >> child frames branch). It fixes the case I mentioned above. > > I'd like to understand why these changes are needed. Could you please > elaborate on each and every change? > >> if (EQ (window, f->menu_bar_window)) >> { >> - cursor =3D FRAME_OUTPUT_DATA (f)->nontext_cursor; >> + if (FRAME_WINDOW_P (f)) >> + cursor =3D FRAME_OUTPUT_DATA (f)->nontext_cursor; > > Can a TTY frame have a menu-bar window? AFAIK, a menu bar is just a > frame glyph row on TTY frames, it is not a window. > >> if (EQ (window, f->tab_bar_window)) >> { >> note_tab_bar_highlight (f, x, y); >> - if (tab_bar__dragging_in_progress) >> - cursor =3D FRAME_OUTPUT_DATA (f)->hand_cursor; >> - else >> - cursor =3D FRAME_OUTPUT_DATA (f)->nontext_cursor; >> + if (FRAME_WINDOW_P (f)) >> + { >> + if (tab_bar__dragging_in_progress) >> + cursor =3D FRAME_OUTPUT_DATA (f)->hand_cursor; >> + else >> + cursor =3D FRAME_OUTPUT_DATA (f)->nontext_cursor; >> + } > > Same question here about tab-bar window. > >> if (EQ (window, f->tool_bar_window)) >> { >> note_tool_bar_highlight (f, x, y); >> - cursor =3D FRAME_OUTPUT_DATA (f)->nontext_cursor; >> + if (FRAME_WINDOW_P (f)) >> + cursor =3D FRAME_OUTPUT_DATA (f)->nontext_cursor; >> goto set_cursor; > > Same question here about tool-bar window. > >> #ifdef HAVE_WINDOW_SYSTEM >> if (part =3D=3D ON_LEFT_MARGIN || part =3D=3D ON_RIGHT_MARGIN) >> { >> - cursor =3D FRAME_OUTPUT_DATA (f)->nontext_cursor; >> + if (FRAME_WINDOW_P (f)) >> + cursor =3D FRAME_OUTPUT_DATA (f)->nontext_cursor; > > This part I could understand. > >> #ifdef HAVE_WINDOW_SYSTEM >> if (part =3D=3D ON_VERTICAL_BORDER) >> { >> - cursor =3D FRAME_OUTPUT_DATA (f)->horizontal_drag_cursor; >> + if (FRAME_WINDOW_P (f)) >> + cursor =3D FRAME_OUTPUT_DATA (f)->horizontal_drag_cursor; > > Do we have vertical borders on TTY frames? If yes, this is also > understood. > >> else if (part =3D=3D ON_RIGHT_DIVIDER) >> { >> - cursor =3D FRAME_OUTPUT_DATA (f)->horizontal_drag_cursor; >> + if (FRAME_WINDOW_P (f)) >> + cursor =3D FRAME_OUTPUT_DATA (f)->horizontal_drag_cursor; >> help_echo_string =3D build_string ("drag-mouse-1: resize"); >> goto set_cursor; > > Do we have right dividers on TTY frames? > >> @@ -36244,7 +36253,8 @@ note_mouse_highlight (struct frame *f, int x, in= t y) >> || minibuf_level >> || NILP (Vresize_mini_windows)) >> { >> - cursor =3D FRAME_OUTPUT_DATA (f)->vertical_drag_cursor; >> + if (FRAME_WINDOW_P (f)) >> + cursor =3D FRAME_OUTPUT_DATA (f)->vertical_drag_cursor; >> help_echo_string =3D build_string ("drag-mouse-1: resize"); > > Same question about bottom dividers as above about right dividers. > >> else if (part =3D=3D ON_LEFT_FRINGE || part =3D=3D ON_RIGHT_FRINGE) >> { >> - cursor =3D FRAME_OUTPUT_DATA (f)->nontext_cursor; >> + if (FRAME_WINDOW_P (f)) >> + cursor =3D FRAME_OUTPUT_DATA (f)->nontext_cursor; > > How can fringes happen on a TTY frame? > >> else if (part =3D=3D ON_VERTICAL_SCROLL_BAR >> || part =3D=3D ON_HORIZONTAL_SCROLL_BAR) >> - cursor =3D FRAME_OUTPUT_DATA (f)->nontext_cursor; >> - else >> + { >> + if (FRAME_WINDOW_P (f)) >> + cursor =3D FRAME_OUTPUT_DATA (f)->nontext_cursor; >> + } >> + else if (FRAME_WINDOW_P (f)) >> cursor =3D FRAME_OUTPUT_DATA (f)->text_cursor; >> #endif > > How can scroll bars happen on TTY frames? I'll try to answer this a bit more broadly: I'd like the code to be more resilient, and not make implicit assumptions about the absence of of features on ttys, which when false, leads to such hard to detect errors. Consider the internal border case. In master, FRAME_INTERNAL_BORDER happens to return 0 in master. But that might change, if I ever get setting internal borders to work for tty child frames, to draw the border there. From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Oct 2024 18:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.172910343326238 (code B ref 73838); Wed, 16 Oct 2024 18:31:02 +0000 Received: (at 73838) by debbugs.gnu.org; 16 Oct 2024 18:30:33 +0000 Received: from localhost ([127.0.0.1]:60467 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t18n3-0006p7-6z for submit@debbugs.gnu.org; Wed, 16 Oct 2024 14:30:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41482) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t18n1-0006kR-AG for 73838@debbugs.gnu.org; Wed, 16 Oct 2024 14:30:32 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t18mb-000547-VD; Wed, 16 Oct 2024 14:30:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=cQxptQMZGuM9bkASaIQGP3oe99FmYiDqB+Jv7GZC9Vo=; b=nA8lYRq00PK/mESgZOxf NLwAKx9mw6ArD61J+Ix6Lo9Cgo6O2fOHzV/RCy/Fp6qdN8xKSELXo4iDR8+IumegQuA58zS3550Hf tf6k2dSqyXl1ozLaB4FdDjMHoNU9Zrrd7SEsxYQMZPvZvDNGNfa4LX7Sc2ZwGBwJE5Ka3pbxm0nj+ gky78p5VTQHoyHksuF1rKso69Gn5ubVGXFogDXmDJG5pGi3PQXL0q44JurKhEq7KAGtwxTD4AP+fa 8dCnCwMKYug7XxbPNWyWl9culkKd6/NLaWUeNFeMIxAGCh2m3pSxfQD+8IpRvFpfNyZs/Q9FFZV70 T3aZ0+4EYHe9PQ==; Date: Wed, 16 Oct 2024 21:30:03 +0300 Message-Id: <86msj3q4t0.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Gerd =?UTF-8?Q?M=C3=B6llmann?= on Wed, 16 Oct 2024 18:56:53 +0200) References: <86r08goy76.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: 73838@debbugs.gnu.org > Date: Wed, 16 Oct 2024 18:56:53 +0200 > > Eli Zaretskii writes: > > > How can scroll bars happen on TTY frames? > > I'll try to answer this a bit more broadly: I'd like the code to be more > resilient, and not make implicit assumptions about the absence of of > features on ttys, which when false, leads to such hard to detect errors. > > Consider the internal border case. In master, FRAME_INTERNAL_BORDER > happens to return 0 in master. But that might change, if I ever get > setting internal borders to work for tty child frames, to draw the > border there. But then we need to audit a lot more than just these bits. E.g., who will guarantee that FRAME_WINDOW_P is always zero on TTY frames? More seriously, I think we should prefer functional tests to declarative tests. Which means not to assume that TTY frames can never have some display feature. Thus, IMO your suggestion is in a sense a step back, because it assumes that TTY frames can never have these decorations and can never have different cursor types. So my suggestion would be to do the opposite: understand why FRAME_OUTPUT_DATA segfaults when dereferenced on TTY frames, and fix that so that it doesn't. From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Oct 2024 19:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.172910548631770 (code B ref 73838); Wed, 16 Oct 2024 19:05:01 +0000 Received: (at 73838) by debbugs.gnu.org; 16 Oct 2024 19:04:46 +0000 Received: from localhost ([127.0.0.1]:60498 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t19K9-0008GL-La for submit@debbugs.gnu.org; Wed, 16 Oct 2024 15:04:46 -0400 Received: from mail-wm1-f52.google.com ([209.85.128.52]:53439) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t19K7-0008G4-AG for 73838@debbugs.gnu.org; Wed, 16 Oct 2024 15:04:44 -0400 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-43117ed8adbso2107885e9.2 for <73838@debbugs.gnu.org>; Wed, 16 Oct 2024 12:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729105397; x=1729710197; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=CIWSmiJpnGG0Aj9OKtRzhQIcbOyMTyHSxJFDcFstslI=; b=ZJ2X0QOlQEWvfnsmKarh4UzVhcY4DjCAgUnW0gKRs695sSsXi7HXoeKoGqw1AEqVMk 5h4mEe2sn27P2DJXB46gSI1qezEo1aZg7z547sW8g/gAmHjRbL9d/LKz8FHJPxLj0XiV dWWEjgIyU46VRy9jdkjkXHTpmR8Yn2YOtJ+VFklhRfsonnoJFEdibtW37tmYTqjxqksm 3izZt8rYNHf8L/0p8zCe6oJhvpWYj3WXtZzuk5MoINpZCSqfdcA0fAPW4eiWFDanfA46 Z9gBp8NWDRojA4re+hYcDs5TH71I0+A6Up906zOz+deHhEpef2oH2p/Hb9W5RN52oT8u 8obg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729105397; x=1729710197; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=CIWSmiJpnGG0Aj9OKtRzhQIcbOyMTyHSxJFDcFstslI=; b=Kb3wsZoiyJzBroF0PDor8f7RZ6MaTrJ3EHT43RbUfTsjNLOATes6HNfmTYLtQ8Ru2+ 524yH5EvnnhysLLikNUzcSLeZkh+knWNrkNFcKeEyHYpY34TUZbbhZSIEFcguIZbcLc4 wLw1UvzVFkkHG9hhtaJUkgggviVWxSTMHm7FeBFZXZJE5/xzyNyiwRrKmeN0yhYsuIu+ Vc1kD79vtHGJ5CZFahxVxaeQNz5/4UFbHSIXzDYs3ukhxE/pE5LnEsOG/022YKz+MQO7 IM3FACLyPzVeG54yMeWHRwb5Y1G41XaIPTEpHfQyV2VjCf8BlLZOqnnOxT906dgaYJdR CN4A== X-Gm-Message-State: AOJu0YyDpsmSlvxnxptaazqAdsSxP9hIsOk+/8N1A1abkVjvkXToYauM jrjpXJ0pdjWpcU0uHulJgywNxfJOUtFb0VVxdKFo8Qyt2oDECpnrAqhYIg== X-Google-Smtp-Source: AGHT+IGVMag6moAqHCPSkXmMdMEECDvJL/KJzLq5pkyKjW73ZsQoLNy889xJNcQ1XzHyzs/064p2dw== X-Received: by 2002:a5d:4f85:0:b0:37d:4833:38f5 with SMTP id ffacd0b85a97d-37d5ffa2e1dmr14259236f8f.30.1729105396948; Wed, 16 Oct 2024 12:03:16 -0700 (PDT) Received: from pro2 (pd9e36c48.dip0.t-ipconnect.de. [217.227.108.72]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-37d7fa87c27sm5016947f8f.39.2024.10.16.12.03.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Oct 2024 12:03:16 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: <86msj3q4t0.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 16 Oct 2024 21:30:03 +0300") References: <86r08goy76.fsf@gnu.org> <86msj3q4t0.fsf@gnu.org> Date: Wed, 16 Oct 2024 21:03:15 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: 73838@debbugs.gnu.org >> Date: Wed, 16 Oct 2024 18:56:53 +0200 >>=20 >> Eli Zaretskii writes: >>=20 >> > How can scroll bars happen on TTY frames? >>=20 >> I'll try to answer this a bit more broadly: I'd like the code to be more >> resilient, and not make implicit assumptions about the absence of of >> features on ttys, which when false, leads to such hard to detect errors. >>=20 >> Consider the internal border case. In master, FRAME_INTERNAL_BORDER >> happens to return 0 in master. But that might change, if I ever get >> setting internal borders to work for tty child frames, to draw the >> border there. > > But then we need to audit a lot more than just these bits. E.g., who > will guarantee that FRAME_WINDOW_P is always zero on TTY frames? Quite unlikely, it's the only way we know what is in the output_data union :-). Anyway. > > More seriously, I think we should prefer functional tests to > declarative tests. Which means not to assume that TTY frames can > never have some display feature.=20=20 That would be good. But if I may add that from my experience with the child frames -- we're far from it. > Thus, IMO your suggestion is in a sense a step back, because it > assumes that TTY frames can never have these decorations and can never > have different cursor types. So my suggestion would be to do the > opposite: understand why FRAME_OUTPUT_DATA segfaults when dereferenced > on TTY frames, and fix that so that it doesn't. But the current situation is that we follow from the presence of an internal border that it's a window system frame. We're using FRAME_OUTPUT_DATA. If that would segv it would be a good thing. It doesn't do that, it just silently accesses some unrelated memory (in my case this is equivalent to casting the actual output_data contents to (struct ns_output *) regardless of what it actually is. I've just dragged the FRAME_WINDOW_P out of this stuff because the whole if-statement is concerned with cursor =3D ... using FRAME_OUTPUT_DATA. From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Oct 2024 04:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.172913815729788 (code B ref 73838); Thu, 17 Oct 2024 04:10:02 +0000 Received: (at 73838) by debbugs.gnu.org; 17 Oct 2024 04:09:17 +0000 Received: from localhost ([127.0.0.1]:32923 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1Hp7-0007kN-C8 for submit@debbugs.gnu.org; Thu, 17 Oct 2024 00:09:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37082) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1Hp4-0007k7-MJ for 73838@debbugs.gnu.org; Thu, 17 Oct 2024 00:09:15 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t1HmY-0001g2-Kt; Thu, 17 Oct 2024 00:06:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=wXn3B67dy+4wxVoFXUtz8WVO0df8CJLXGA2mkNJehms=; b=HXsgEhE2l4NzQQGjOF4r hF3EoHXnXz7AXinNkXzgnfJc+YS+Jqh19CDOmQrY5u+A5PG0zH9UDwOeeZyouC12IGNwlhyfViyeT pLIO0HTPqV4xsTUuKJHh0UwbDHHexlrKCpzZgWIxHAr+jhV53etjEAXu3/88dGw8ZSTA+A3WqHWrB 3FGSXfBQ8BBf6f9XveR0fAdi1YsxbKbY9igmkW9PsGIp8AMNvUoDSciohpxPHsatVq1sHmdKuMpR0 cvYmp4snNi6ggATZanIWAMYCXrXyrskjC2W7IHD4YnFYxdQDhmxpDG9r/9C97pqi4DZb9OF5u9VSw 9hh5MR5UP72ogA==; Date: Thu, 17 Oct 2024 07:06:33 +0300 Message-Id: <86iktrpe46.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Gerd =?UTF-8?Q?M=C3=B6llmann?= on Wed, 16 Oct 2024 21:03:15 +0200) References: <86r08goy76.fsf@gnu.org> <86msj3q4t0.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: 73838@debbugs.gnu.org > Date: Wed, 16 Oct 2024 21:03:15 +0200 > > > Thus, IMO your suggestion is in a sense a step back, because it > > assumes that TTY frames can never have these decorations and can never > > have different cursor types. So my suggestion would be to do the > > opposite: understand why FRAME_OUTPUT_DATA segfaults when dereferenced > > on TTY frames, and fix that so that it doesn't. > > But the current situation is that we follow from the presence of an > internal border that it's a window system frame. We're using > FRAME_OUTPUT_DATA. If that would segv it would be a good thing. It > doesn't do that, it just silently accesses some unrelated memory (in my > case this is equivalent to casting the actual output_data contents to > (struct ns_output *) regardless of what it actually is. > > I've just dragged the FRAME_WINDOW_P out of this stuff because the > whole if-statement is concerned with cursor = ... using FRAME_OUTPUT_DATA. My suggestion is to extend 'struct tty_display_info' so that FRAME_OUTPUT_DATA on TTY frames will not access unrelated memory, when these macros/inline functions are called. Alternatively, we could have the macros/functions (FRAME_INTERNAL_BORDER etc.) test for TTY frame and DTRT. From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Oct 2024 05:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.17291417568371 (code B ref 73838); Thu, 17 Oct 2024 05:10:02 +0000 Received: (at 73838) by debbugs.gnu.org; 17 Oct 2024 05:09:16 +0000 Received: from localhost ([127.0.0.1]:33033 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1Il9-0002Aw-GQ for submit@debbugs.gnu.org; Thu, 17 Oct 2024 01:09:15 -0400 Received: from mail-wm1-f44.google.com ([209.85.128.44]:47164) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1Il6-0002Ai-VI for 73838@debbugs.gnu.org; Thu, 17 Oct 2024 01:09:13 -0400 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4314c4cb752so5383855e9.2 for <73838@debbugs.gnu.org>; Wed, 16 Oct 2024 22:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729141666; x=1729746466; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=brupAr7YpdB1Ia3U0U9m/iOMb/prcv1S4SYu/Xr/vKo=; b=N8ZEUkGxuw136qA4Is5XPeSw7UiAvA2BjsDbhzdiLsIMyL3V1aqj/rkmlUzuzp7z2D 3sW+KGeKo8pE1yFnk9vt0EovIu03K8NeQGzm6Sa49pASX3JzSf1YaQiI2+vxzUADep0E RBYbtILwceAml6cTHuORt4WRwCfOpfaCWOYfnPE3Af8gFNBOYt4LjtqF90ITVyHIG3Fp uyoyNxS9VkyiYSwPIVw9dGmS+Lz4DTbEq5WkUVcV3e+zK9E1+iU2+RtjEeyTH+jQMOts QKPMNq7RWVas2FKWvXFi/UTLiB/TNNBv0rqhEQQdwyD00vwbFDXYptJAcx0D+KimNODh rHvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729141666; x=1729746466; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=brupAr7YpdB1Ia3U0U9m/iOMb/prcv1S4SYu/Xr/vKo=; b=sYLIEc9dNc7GHZXti0cu96Y5z40O9jYJY4tUpk/lq3uwSLZG1yVvcyRZY5tMOXvYMZ zP9l+tK2trjgRk1r5GaA5nhQDiEqwU0fmm6qrnh9R7Btfxp4lNjK/giFEB8YcRuK/9/C ZCf2OP5/zN7m8nUyhzrMG4Xo+oLHICWOZNW7aUGSbKwxYB5/pbf/7iAy+TjRJBOXeb8l c6yH3EjzRAZhRCdLtp0YJZ8StW/2MEa7jYFZO4PIRVNdc/KJWcOnzO16ef4Brz6DqK7s H5JS9k3b15js25qwyt+j4kT8/BW7ZMnMY2fQ6vfdSJZoSD7kQXlqV9dfvy4HWvbWVdqO qF/g== X-Gm-Message-State: AOJu0YwhrX23SsrDv+OwVSjYqRAInnAAIQgtddilbt8WhNx3YvoOlmeo 59Pe88G56ouKUMMvoRuD1kSE3UA2CgC4/zaDQ2t90YIfnwtifXAjMyMdXg== X-Google-Smtp-Source: AGHT+IHFqqkGLYkONJ6EiQxSxQDql817KefuhnMaVZuyOykm/49LAhUlz/CSiyfwezj6wkJjBXrP6A== X-Received: by 2002:a05:600c:5248:b0:42c:b5f1:44ff with SMTP id 5b1f17b1804b1-4311df56fc6mr201462095e9.24.1729141665727; Wed, 16 Oct 2024 22:07:45 -0700 (PDT) Received: from pro2 (pd9e36829.dip0.t-ipconnect.de. [217.227.104.41]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43158c5062csm13144345e9.41.2024.10.16.22.07.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Oct 2024 22:07:45 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: <86iktrpe46.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 17 Oct 2024 07:06:33 +0300") References: <86r08goy76.fsf@gnu.org> <86msj3q4t0.fsf@gnu.org> <86iktrpe46.fsf@gnu.org> Date: Thu, 17 Oct 2024 07:07:44 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: 73838@debbugs.gnu.org >> Date: Wed, 16 Oct 2024 21:03:15 +0200 >>=20 >> > Thus, IMO your suggestion is in a sense a step back, because it >> > assumes that TTY frames can never have these decorations and can never >> > have different cursor types. So my suggestion would be to do the >> > opposite: understand why FRAME_OUTPUT_DATA segfaults when dereferenced >> > on TTY frames, and fix that so that it doesn't. >>=20 >> But the current situation is that we follow from the presence of an >> internal border that it's a window system frame. We're using >> FRAME_OUTPUT_DATA. If that would segv it would be a good thing. It >> doesn't do that, it just silently accesses some unrelated memory (in my >> case this is equivalent to casting the actual output_data contents to >> (struct ns_output *) regardless of what it actually is. >>=20 >> I've just dragged the FRAME_WINDOW_P out of this stuff because the >> whole if-statement is concerned with cursor =3D ... using FRAME_OUTPUT_D= ATA. > > My suggestion is to extend 'struct tty_display_info' so that > FRAME_OUTPUT_DATA on TTY frames will not access unrelated memory, when > these macros/inline functions are called. Alternatively, we could have > the macros/functions (FRAME_INTERNAL_BORDER etc.) test for TTY frame > and DTRT. FRAME_OUTPUT_DATA is meaningful only for window system frames. Each window system's "term" header defines it. For example xterm.h: #define FRAME_X_OUTPUT(f) ((f)->output_data.x) #define FRAME_OUTPUT_DATA(f) FRAME_X_OUTPUT (f) nsterm.h: #define FRAME_OUTPUT_DATA(f) ((f)->output_data.ns) and so on. So using FRAME_OUTPUT_DATA is per se only valid if FRAME_WINDOW_P. Which is equivalent to FRAME_NS_P in my case, or whatever someone uses. #ifdef HAVE_X_WINDOWS #define FRAME_WINDOW_P(f) FRAME_X_P (f) #endif #ifdef HAVE_NS #define FRAME_WINDOW_P(f) FRAME_NS_P(f) #endif #ifndef FRAME_WINDOW_P #define FRAME_WINDOW_P(f) ((void) (f), false) #endif I think changing that would be a major surgery. It's probably easier to add checks like I did in the patch to FRAME_OUTPUT_DATA if the frame in questioin is indeed a window system frame. It can be decided at run-time only anyway. The other idea is, IIUC, is to make code using FRAME_OUTPUT_DATA like this one if (FRAME_INTERNAL_BORDER_WIDTH (f) > 0 && !NILP (get_frame_param (f, Qdrag_internal_border))) { enum internal_border_part part =3D frame_internal_border_part (f, x, = y); switch (part) { case INTERNAL_BORDER_NONE: if (cursor !=3D FRAME_OUTPUT_DATA (f)->nontext_cursor) /* Reset cursor. */ cursor =3D FRAME_OUTPUT_DATA (f)->nontext_cursor; work by making sure that their if-conditions can't be true, if there any. In the above case by making FRAME_INTERNAL_BORDER_WIDTH return 0 if the frame is not FRAME_WINDOW_P. In other cases like this one if (EQ (window, f->tool_bar_window)) { note_tool_bar_highlight (f, x, y); cursor =3D FRAME_OUTPUT_DATA (f)->nontext_cursor; or here if (part =3D=3D ON_MODE_LINE || part =3D=3D ON_HEADER_LINE || part =3D=3D= ON_TAB_LINE || part =3D=3D ON_LEFT_MARGIN || part =3D=3D ON_RIGHT_MARGIN) { note_mode_line_or_margin_highlight (window, x, y, part); #ifdef HAVE_WINDOW_SYSTEM if (part =3D=3D ON_LEFT_MARGIN || part =3D=3D ON_RIGHT_MARGIN) { cursor =3D FRAME_OUTPUT_DATA (f)->nontext_cursor; /* Show non-text cursor (Bug#16647). */ goto set_cursor; } else #endif return; } by doing something else. I have to admit that I don't like that. I don't understand what is wrong to check FRAME_WINDOW_P before using something (using FRAME_OUTPUT_DATA) that requires FRAME_WINDOW_P to be valid. From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Oct 2024 05:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.172914416815840 (code B ref 73838); Thu, 17 Oct 2024 05:50:02 +0000 Received: (at 73838) by debbugs.gnu.org; 17 Oct 2024 05:49:28 +0000 Received: from localhost ([127.0.0.1]:33096 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1JO3-00047O-QY for submit@debbugs.gnu.org; Thu, 17 Oct 2024 01:49:28 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49970) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1JO0-000476-79 for 73838@debbugs.gnu.org; Thu, 17 Oct 2024 01:49:25 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t1JNa-0003C2-BK; Thu, 17 Oct 2024 01:48:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=xncBqViyquqslVg2QiXvOzYoL2VrZci/2LqP64sVY2A=; b=mhjXX72RowbUkbffPz85 9OAYoAYoCumYLKD3WOvf9viLODae1dBTy5EyW2yje9jdPOUM9NoSljxL/VzioSvNk2hicfc8RP4TK wy2dZJ6O0ULfEoQN2x/C3emedXyNpEmH2faNwn1iOcSp1Sk/S+/oWbcBFPnzvWJWt/17zLX5GUpi8 Up4nvb/RMrIg3DYTKPZqibTSQUmoETc/Q7PmKvj1mpa7ZHwhZqLNycjxpTyGk1QSh5uSYK1bFvoix +/ckUVx02uTHAi8nq/HBCsOONtuwkWJ7c4QQ2HinratJOzfkqGGueF+fmRWJ092WaNse5vpZED4sW ibLa7uqot1jyhw==; Date: Thu, 17 Oct 2024 08:48:56 +0300 Message-Id: <86cyjzp9dj.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Gerd =?UTF-8?Q?M=C3=B6llmann?= on Thu, 17 Oct 2024 07:07:44 +0200) References: <86r08goy76.fsf@gnu.org> <86msj3q4t0.fsf@gnu.org> <86iktrpe46.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: 73838@debbugs.gnu.org > Date: Thu, 17 Oct 2024 07:07:44 +0200 > > Eli Zaretskii writes: > > > My suggestion is to extend 'struct tty_display_info' so that > > FRAME_OUTPUT_DATA on TTY frames will not access unrelated memory, when > > these macros/inline functions are called. Alternatively, we could have > > the macros/functions (FRAME_INTERNAL_BORDER etc.) test for TTY frame > > and DTRT. > > FRAME_OUTPUT_DATA is meaningful only for window system frames. Each > window system's "term" header defines it. For example > > xterm.h: > #define FRAME_X_OUTPUT(f) ((f)->output_data.x) > #define FRAME_OUTPUT_DATA(f) FRAME_X_OUTPUT (f) > > nsterm.h: > #define FRAME_OUTPUT_DATA(f) ((f)->output_data.ns) > > and so on. So using FRAME_OUTPUT_DATA is per se only valid if > FRAME_WINDOW_P. Which is equivalent to FRAME_NS_P in my case, or > whatever someone uses. > > #ifdef HAVE_X_WINDOWS > #define FRAME_WINDOW_P(f) FRAME_X_P (f) > #endif > #ifdef HAVE_NS > #define FRAME_WINDOW_P(f) FRAME_NS_P(f) > #endif > #ifndef FRAME_WINDOW_P > #define FRAME_WINDOW_P(f) ((void) (f), false) > #endif My suggestion is to change the last part. output_data is defined like so: union output_data { struct tty_output *tty; /* From termchar.h. */ struct x_output *x; /* From xterm.h. */ struct w32_output *w32; /* From w32term.h. */ struct ns_output *ns; /* From nsterm.h. */ struct pgtk_output *pgtk; /* From pgtkterm.h. */ struct haiku_output *haiku; /* From haikuterm.h. */ struct android_output *android; /* From androidterm.h. */ } output_data; So it exists in TTY frames as well, and we could have bitfields in it that correspond to the window-system's versions of output_data to specify internal-border and other decorations. We just need to make sure these bitfields are zero as long as TTY frames don't support those features. Then we could avoid the FRAME_WINDOW_P tests which you propose to add, and still have valid and future-proof code. I thought you were proposing a future-proof change that will avoid the need to dig into these macros and change them if and when TTY frames gain more functionality. If that's not what you are suggesting, I wonder what is wrong with the current code that we need to make changes which are basically half-solutions. If the problem is access to unrelated memory, that is easy to fix by just adding enough slack to tty_output definition, for example. Adding tests slows down redisplay, albeit by a very small amount in each case (but these slow-downs add up, since we use these macros all over the place). > I think changing that would be a major surgery. It's probably easier to > add checks like I did in the patch to FRAME_OUTPUT_DATA if the frame in > questioin is indeed a window system frame. It can be decided at run-time > only anyway. It might be easier, but if we are going to make changes, why not do it the right way to begin with? After all, if what's problematic in the current code is that valgrind or ASAN complain, we could simply regard that as false positives, since there are no problems in production builds. > The other idea is, IIUC, is to make code using FRAME_OUTPUT_DATA like > this one > > if (FRAME_INTERNAL_BORDER_WIDTH (f) > 0 > && !NILP (get_frame_param (f, Qdrag_internal_border))) > { > enum internal_border_part part = frame_internal_border_part (f, x, y); > > switch (part) > { > case INTERNAL_BORDER_NONE: > if (cursor != FRAME_OUTPUT_DATA (f)->nontext_cursor) > /* Reset cursor. */ > cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; > > work by making sure that their if-conditions can't be true, if there > any. In the above case by making FRAME_INTERNAL_BORDER_WIDTH return 0 if the > frame is not FRAME_WINDOW_P. In other cases like this one > > if (EQ (window, f->tool_bar_window)) > { > note_tool_bar_highlight (f, x, y); > cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; > > or here > > if (part == ON_MODE_LINE || part == ON_HEADER_LINE || part == ON_TAB_LINE > || part == ON_LEFT_MARGIN || part == ON_RIGHT_MARGIN) > { > note_mode_line_or_margin_highlight (window, x, y, part); > > #ifdef HAVE_WINDOW_SYSTEM > if (part == ON_LEFT_MARGIN || part == ON_RIGHT_MARGIN) > { > cursor = FRAME_OUTPUT_DATA (f)->nontext_cursor; > /* Show non-text cursor (Bug#16647). */ > goto set_cursor; > } > else > #endif > return; > } > > by doing something else. > > I have to admit that I don't like that. I don't understand what is wrong > to check FRAME_WINDOW_P before using something (using FRAME_OUTPUT_DATA) > that requires FRAME_WINDOW_P to be valid. Let me try explaining once again what I think is wrong with testing FRAME_WINDOW_P in each of those cases. Imagine that someone develops a feature whereby TTY frames could have scroll bars or fringes. With the method you propose, we'd then need to change all the places where the code accesses scroll bars or fringes, and remove the FRAME_WINDOW_P and similar tests. If some of these tests are forgotten and not removed/rewritten, we'd have a subtle bug. By contrast, the way I propose it, whereby tty_output will have extended to have the corresponding fields, all we'd need is to set those fields to some non-zero values, and the rest will "just work". IOW, my proposal is to make the tests be based on supported functionalities rather than on some attribute of a frame which _today_ is associated with the lack of such functionalities, for the same reasons we prefer testing functionalities with HAVE_SOMETHING to testing version numbers or OS-specific symbols. Because the correlation between frame types and available functionalities can change in the future, and then adjusting the code to such changes is usually a tedious and error-prone job. We had ample examples of that when TTY frames learned to display colors, then again when they learned to show menus and dialogs. We should learn from those examples. From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Oct 2024 07:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.172914868628734 (code B ref 73838); Thu, 17 Oct 2024 07:05:02 +0000 Received: (at 73838) by debbugs.gnu.org; 17 Oct 2024 07:04:46 +0000 Received: from localhost ([127.0.0.1]:33180 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1KYv-0007TN-AT for submit@debbugs.gnu.org; Thu, 17 Oct 2024 03:04:45 -0400 Received: from mail-wm1-f48.google.com ([209.85.128.48]:60502) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1KYt-0007T8-V1 for 73838@debbugs.gnu.org; Thu, 17 Oct 2024 03:04:44 -0400 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4315df7b43fso661705e9.0 for <73838@debbugs.gnu.org>; Thu, 17 Oct 2024 00:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729148597; x=1729753397; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=qHYCtEdVs2/pdoNDVn+PDCLTV7wWZe1qGd7Z6ouTJV0=; b=IFF0h087Qgv/gKtP2tADLxpy6v1bV+BuaugefJP4VQ0FA5Do1encj+SoF0FZq7F/3u 1anwG7npweckRATwZ5lQOYeqDwJOlEpgigLHm2aQ57F5TdVRQ5YbKMt6ybF8qy27L+/e jPogKqtIvnoP3635+RcRzBFIqaE04AZrWw04ftH9D+mfedXgWNBIXw8uXnMunXP1GO4c 726acJxTnH4xZe4ipveT/X/7XE3sGB8dN9xcqYbA+ulNL0Rp8JgLcxyWZ4+fD2XXYjXu yYBPAjx2o0wuIldAZp28X8UToSzsxfIcuvpjUFjHAfdl+d1x/bdlUSmGOE3nB9IRobtX sVVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729148597; x=1729753397; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=qHYCtEdVs2/pdoNDVn+PDCLTV7wWZe1qGd7Z6ouTJV0=; b=iulRQFLYLi+kbw4rowS66tFS6IWmJcjBFqFfv0RM1+sg88g7iqQa7HDiPk8WFtIhdn /p3RbAO7KPNfDub0CXcOLhVPQ4gqiOxan01PfczLdOufK/fRirH1q5RL1Kbo5FrbxcSl V+3YKHVBfwcJ9Rx8a/2vKD0HDOrzSaZ78sc36E+MDVhcyL5L0VkXG5WdcI3P0vkFLL47 u6dZLSaAT257XyMilVETex7GELR5m9KMRlobSOdloD6+fG/x7BNQu3cASbRQJV0e3tF5 +AZynCuzY/9OP5UY31bCs/ujghtFji3vqcHKK7cQNgBr0ZkoupEUASRB7PAgxHRm++Q7 mW5w== X-Gm-Message-State: AOJu0YzTmvPMQbHEGm50aHJWfuzJrqUCaoPQ/3PsZuHYiHX9npvqrqus F7nBETbptTKJBhzRhwqP+r0bHvMFjm3J8Y/DBeV6L5Y1CsGwSygJfd7NvQ== X-Google-Smtp-Source: AGHT+IEHCiNORnH1RzoMJF5d9q7eH+x/1MFM59ZmKWv3ehuhFb51GPQiPySGnM2LDRWxa9EQFpFK+g== X-Received: by 2002:a05:600c:4f46:b0:431:5a0e:fa2e with SMTP id 5b1f17b1804b1-4315a0efb12mr9644365e9.21.1729148596752; Thu, 17 Oct 2024 00:03:16 -0700 (PDT) Received: from pro2 (pd9e36829.dip0.t-ipconnect.de. [217.227.104.41]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43158c39cafsm16049185e9.16.2024.10.17.00.03.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Oct 2024 00:03:16 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: <86cyjzp9dj.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 17 Oct 2024 08:48:56 +0300") References: <86r08goy76.fsf@gnu.org> <86msj3q4t0.fsf@gnu.org> <86iktrpe46.fsf@gnu.org> <86cyjzp9dj.fsf@gnu.org> Date: Thu, 17 Oct 2024 09:03:13 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: 73838@debbugs.gnu.org >> Date: Thu, 17 Oct 2024 07:07:44 +0200 >>=20 >> Eli Zaretskii writes: >>=20 >> > My suggestion is to extend 'struct tty_display_info' so that >> > FRAME_OUTPUT_DATA on TTY frames will not access unrelated memory, when >> > these macros/inline functions are called. Alternatively, we could have >> > the macros/functions (FRAME_INTERNAL_BORDER etc.) test for TTY frame >> > and DTRT. >>=20 >> FRAME_OUTPUT_DATA is meaningful only for window system frames. Each >> window system's "term" header defines it. For example >>=20 >> xterm.h: >> #define FRAME_X_OUTPUT(f) ((f)->output_data.x) >> #define FRAME_OUTPUT_DATA(f) FRAME_X_OUTPUT (f) >>=20 >> nsterm.h: >> #define FRAME_OUTPUT_DATA(f) ((f)->output_data.ns) >>=20 >> and so on. So using FRAME_OUTPUT_DATA is per se only valid if >> FRAME_WINDOW_P. Which is equivalent to FRAME_NS_P in my case, or >> whatever someone uses. >>=20 >> #ifdef HAVE_X_WINDOWS >> #define FRAME_WINDOW_P(f) FRAME_X_P (f) >> #endif >> #ifdef HAVE_NS >> #define FRAME_WINDOW_P(f) FRAME_NS_P(f) >> #endif >> #ifndef FRAME_WINDOW_P >> #define FRAME_WINDOW_P(f) ((void) (f), false) >> #endif > > My suggestion is to change the last part. output_data is defined like > so: > > union output_data > { > struct tty_output *tty; /* From termchar.h. */ > struct x_output *x; /* From xterm.h. */ > struct w32_output *w32; /* From w32term.h. */ > struct ns_output *ns; /* From nsterm.h. */ > struct pgtk_output *pgtk; /* From pgtkterm.h. */ > struct haiku_output *haiku; /* From haikuterm.h. */ > struct android_output *android; /* From androidterm.h. */ > } > output_data; > > So it exists in TTY frames as well, and we could have bitfields in it > that correspond to the window-system's versions of output_data to > specify internal-border and other decorations. We just need to make > sure these bitfields are zero as long as TTY frames don't support > those features. Then we could avoid the FRAME_WINDOW_P tests which > you propose to add, and still have valid and future-proof code. Ok, I think I understand that. That requires some "base class" design so to speak, which all the xy_output types "inherit" from, right? We don't have that ATM, at least not for NS and X. I agree that would be nice. But it's a lot of work, and probably involves changing code for all platforms. Which I can't. > I thought you were proposing a future-proof change that will avoid the > need to dig into these macros and change them if and when TTY frames > gain more functionality. Well how can I put it. I have actually two problems, let my try to explain :-). The immediate problem I'm facing is with tty child frames and xterm-mouse: I'm opening a buffer selection child frame (consult-buffer) and choose a candidate with a mouse click. The candidates are mouse-highlighted. Result is eventually an endless loop in process_mark_stack in the non-MPS GC. (Not using the mouse works just fine.) Enabling chekcing to the max shhows nothing, so I build with ASAN. And I'm getting stuck early because ASAN shows the invalid access via FRAME_OUTPUT_DATA this bug is about. My second, more general, problem is that the different types of frames are handled so differently in our code, and that it's so difficult to get things to work. I think I've spent at least 90% of the time I spent with child frames with that. The internal-border stuff is an example. I tried to add that for tty frames, for the borders, and it was such a mess (even behaving differently if HVE_WINDOW_SYSTEM or not, i.e. configuring --without-ns or --with-ns) that I git reset --hard in a rage in the end :-). I'd be quite interested to improve that situation, but I'd rather get so far that I can tackle my immediate problem. > If that's not what you are suggesting, I > wonder what is wrong with the current code that we need to make > changes which are basically half-solutions. If the problem is access > to unrelated memory, that is easy to fix by just adding enough slack > to tty_output definition, for example. You mean by making sizeof (struct tty_output) =3D=3D sizeof (ns_output) in my case, and let it go? Bloodcurdlingly horrible! I don't even want to think about it. > Adding tests slows down > redisplay, albeit by a very small amount in each case (but these > slow-downs add up, since we use these macros all over the place). > >> I think changing that would be a major surgery. It's probably easier to >> add checks like I did in the patch to FRAME_OUTPUT_DATA if the frame in >> questioin is indeed a window system frame. It can be decided at run-time >> only anyway. > > It might be easier, but if we are going to make changes, why not do it > the right way to begin with? After all, if what's problematic in the > current code is that valgrind or ASAN complain, we could simply regard > that as false positives, since there are no problems in production > builds. A "false positive" that provents me from using ASAN to find a real problem. > >> The other idea is, IIUC, is to make code using FRAME_OUTPUT_DATA like >> this one >>=20 ... >> I have to admit that I don't like that. I don't understand what is wrong >> to check FRAME_WINDOW_P before using something (using FRAME_OUTPUT_DATA) >> that requires FRAME_WINDOW_P to be valid. > > Let me try explaining once again what I think is wrong with testing > FRAME_WINDOW_P in each of those cases. Imagine that someone develops > a feature whereby TTY frames could have scroll bars or fringes. With > the method you propose, we'd then need to change all the places where > the code accesses scroll bars or fringes, and remove the > FRAME_WINDOW_P and similar tests. If some of these tests are > forgotten and not removed/rewritten, we'd have a subtle bug. By > contrast, the way I propose it, whereby tty_output will have extended > to have the corresponding fields, all we'd need is to set those fields > to some non-zero values, and the rest will "just work". > > IOW, my proposal is to make the tests be based on supported > functionalities rather than on some attribute of a frame which _today_ > is associated with the lack of such functionalities, for the same > reasons we prefer testing functionalities with HAVE_SOMETHING to > testing version numbers or OS-specific symbols. Because the > correlation between frame types and available functionalities can > change in the future, and then adjusting the code to such changes is > usually a tedious and error-prone job. We had ample examples of that > when TTY frames learned to display colors, then again when they > learned to show menus and dialogs. We should learn from those > examples. I'm think I understand that. And I can understand that you are not interested unless a "grander" solution is available, maybe something like the "base class" approach I tried to describe above. So be it. I think you can as well close this bug as wontfix. It's unlikely that I'll work in the direction you would like to see in the forseeable future. From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Oct 2024 10:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.17291620362570 (code B ref 73838); Thu, 17 Oct 2024 10:48:02 +0000 Received: (at 73838) by debbugs.gnu.org; 17 Oct 2024 10:47:16 +0000 Received: from localhost ([127.0.0.1]:33529 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1O2G-0000fM-27 for submit@debbugs.gnu.org; Thu, 17 Oct 2024 06:47:16 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46824) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1O2E-0000f6-B2 for 73838@debbugs.gnu.org; Thu, 17 Oct 2024 06:47:14 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t1O1o-0008LX-5M; Thu, 17 Oct 2024 06:46:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=PaxLJoqQd/e7IVoCpPEGwJYpKE/NEJDT3Nhye+v5a7g=; b=TE7QoZc3OpxMnFAuP8Li KHyXxk1GK7zo42O/OFpGDp+vMaDLXw5Uecl7nUSMp4Ws1rbxbZJ9g7RyEKdJdpwUa9FPXdTsfCZ0B a18uVUkBVtwahAWwG0JqcoTnISu/LA4DFJAjYXMQ4lcc5CNOhSE0Ek7wBNLUqggK9kaTIyvf07tRh WBGFmGWSfMCpKVXb7kZ4i8fDzmaJaJ5jFD3fOfeLwb9/QjTRLAuM3SSjzr77UAeabFtVCShXT66Qz TN0jXNj3GNrMZT1Uda/hYDGAMpdp8/DHK+HvIGsV93zGNlerL9ce0d5j6wAb8OAnFBOFMc4w24ydd zg1mTtcYQnneqw==; Date: Thu, 17 Oct 2024 13:46:33 +0300 Message-Id: <865xprovli.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Gerd =?UTF-8?Q?M=C3=B6llmann?= on Thu, 17 Oct 2024 09:03:13 +0200) References: <86r08goy76.fsf@gnu.org> <86msj3q4t0.fsf@gnu.org> <86iktrpe46.fsf@gnu.org> <86cyjzp9dj.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: 73838@debbugs.gnu.org > Date: Thu, 17 Oct 2024 09:03:13 +0200 > > The immediate problem I'm facing is with tty child frames and > xterm-mouse: I'm opening a buffer selection child frame (consult-buffer) > and choose a candidate with a mouse click. The candidates are > mouse-highlighted. Result is eventually an endless loop in > process_mark_stack in the non-MPS GC. (Not using the mouse works just > fine.) If you can show the details of that, i.e. step through the loop one time until it gets to the same point, maybe someone could have an idea. From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Oct 2024 10:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.17291620532604 (code B ref 73838); Thu, 17 Oct 2024 10:48:02 +0000 Received: (at 73838) by debbugs.gnu.org; 17 Oct 2024 10:47:33 +0000 Received: from localhost ([127.0.0.1]:33533 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1O2X-0000fv-Cg for submit@debbugs.gnu.org; Thu, 17 Oct 2024 06:47:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51962) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1O2V-0000fg-4H for 73838@debbugs.gnu.org; Thu, 17 Oct 2024 06:47:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t1Nzy-000855-W9; Thu, 17 Oct 2024 06:44:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=zns40pnjgv/l6tT3VPuIXhRNXQy5U0lDZHE8OGiR93E=; b=nBMEID8Jt33tBzX3inQV OrCrNpBNjj0n33vuVNWL0KrAtty62QljY+c3Hcnkh+h0SrcqzwDrbCLamjAchkY3m5t1w7nanCNKN 6ePu6UZuNt5VwyFG7UZqZnmsfiZJ2g3rYz+fR7Vnyuw254FfCmnjTI/9Mbs6kiAHtmgRMJ5XwvEYG Kd3oCB8NP3vi3HqEt8P6AKFE9UBhXBkhr6tHuSelkz3bQvizYjdPd7xGPq+oNZ3c7clpM0d7KoBmx Nb87WW+RD1lmUmYHrjASjCAmSradotJBcYb8T5Hyls9F4EtxVdyDTiDgOl18d3vnykbAqtNxGIRRj 42CX/FCcvuRVFw==; Date: Thu, 17 Oct 2024 13:44:52 +0300 Message-Id: <867ca7ovob.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Gerd =?UTF-8?Q?M=C3=B6llmann?= on Thu, 17 Oct 2024 09:03:13 +0200) References: <86r08goy76.fsf@gnu.org> <86msj3q4t0.fsf@gnu.org> <86iktrpe46.fsf@gnu.org> <86cyjzp9dj.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: 73838@debbugs.gnu.org > Date: Thu, 17 Oct 2024 09:03:13 +0200 > > Eli Zaretskii writes: > > > If that's not what you are suggesting, I > > wonder what is wrong with the current code that we need to make > > changes which are basically half-solutions. If the problem is access > > to unrelated memory, that is easy to fix by just adding enough slack > > to tty_output definition, for example. > > You mean by making sizeof (struct tty_output) == sizeof (ns_output) in > my case, and let it go? Bloodcurdlingly horrible! I don't even want to > think about it. Why is it a problem to add some dummy buffer to a struct? what's so horrible about that? The reason is to let ASAN build run without false positives. Alternatively, cannot you tell ASAN in some way that this code is okay? > I'm think I understand that. And I can understand that you are not > interested unless a "grander" solution is available, maybe something > like the "base class" approach I tried to describe above. So be it. > > I think you can as well close this bug as wontfix. It's unlikely that > I'll work in the direction you would like to see in the forseeable > future. Understood. From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Oct 2024 12:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.172916721617599 (code B ref 73838); Thu, 17 Oct 2024 12:14:01 +0000 Received: (at 73838) by debbugs.gnu.org; 17 Oct 2024 12:13:36 +0000 Received: from localhost ([127.0.0.1]:33650 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1PNn-0004Zm-KF for submit@debbugs.gnu.org; Thu, 17 Oct 2024 08:13:35 -0400 Received: from mail-wm1-f50.google.com ([209.85.128.50]:51412) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1PNl-0004ZX-H2 for 73838@debbugs.gnu.org; Thu, 17 Oct 2024 08:13:34 -0400 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4315abed18aso5397765e9.2 for <73838@debbugs.gnu.org>; Thu, 17 Oct 2024 05:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729167126; x=1729771926; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=8NU4g8EhFvAVaIGY6xpi8E9i9M78B9PJORcsASdusJE=; b=N7qcpIxhNAwqs7C+EFmxXslaTJ4P6qJtNgfYymYLXXwlwJ3e3N2n4nZ7FYaRarfXKe RfLYPw6tX2FjcOHa5S60KCbdafoimrmNwbuuiq4G0WapCAyUebJApWvMSNeC31bdGihU gtrV+wvAHpk+XV5PrTZoJ7YM7XeXRfZ+A+y5EwyZ97CVP+eIY7UDhDM03sNvXAjMgeHP ckZMtl8PpFHi7s91WsXiw26ojNFOwcbLKFffCpsvTxR0rvtaCsOyFUCkJanwoMs92gGX jdb2nFKNLPWm8Nx3X22gdg3zHVYGIAG1cFrjU/iIHuscneDX0XiUNnGXFYy2VoxbP9y8 CNjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729167126; x=1729771926; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=8NU4g8EhFvAVaIGY6xpi8E9i9M78B9PJORcsASdusJE=; b=T6K6S4yVB+KbEBrLGqf4U/1Fup1nEX6m25zyen89PmQf8A3jaY4QEFe1pJK2EqWih1 MDRJICVGd0ZnR4UryNb/AJWWjQE1FHqp3Ye0Io+yOTfkWauafrUCbckyR8oTC6vpw2b2 22iZ/qZFYqWmNg8Mi0W/C/XPyhSJz7ZFrmRNGS407hEjbQ2/rG1nTN8tYmrDnnLflaC3 2mcwbJeMOvl17Oaqc5DHkbHSqzwGuGWvn1/iP1nMT4XrY6OIzq41Es8HYVEqy9AYQuSD Awv8O7UHJxDsFCzPsPXFex+FZhzIeqX9V9FAeB0azj9hG3Cua7U8itrEnWa95YcUxlhg oG7g== X-Gm-Message-State: AOJu0YzmZhlVtZx6+uBz+jPHa4sYVdG/rEW7ocFJttt6c58KaCp0empB pJqFBHOUPuOFB7mbO0yTi9DIWUHWSAJbyTlQU9eAj8weIdVa166MdZuVbw== X-Google-Smtp-Source: AGHT+IEMXruQaAqCEMTseP41VfWcD7Hdrx4qVFtzEM1j4GZGrw53ihrdt3ncD2pJf8S9QuzKips4iQ== X-Received: by 2002:a05:600c:5251:b0:426:64a2:5362 with SMTP id 5b1f17b1804b1-431255dc80cmr151496045e9.8.1729167126279; Thu, 17 Oct 2024 05:12:06 -0700 (PDT) Received: from pro2 (pd9e36829.dip0.t-ipconnect.de. [217.227.104.41]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43158c61b20sm24227355e9.42.2024.10.17.05.12.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Oct 2024 05:12:05 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: <867ca7ovob.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 17 Oct 2024 13:44:52 +0300") References: <86r08goy76.fsf@gnu.org> <86msj3q4t0.fsf@gnu.org> <86iktrpe46.fsf@gnu.org> <86cyjzp9dj.fsf@gnu.org> <867ca7ovob.fsf@gnu.org> Date: Thu, 17 Oct 2024 14:12:03 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: 73838@debbugs.gnu.org >> Date: Thu, 17 Oct 2024 09:03:13 +0200 >>=20 >> Eli Zaretskii writes: >>=20 >> > If that's not what you are suggesting, I >> > wonder what is wrong with the current code that we need to make >> > changes which are basically half-solutions. If the problem is access >> > to unrelated memory, that is easy to fix by just adding enough slack >> > to tty_output definition, for example. >>=20 >> You mean by making sizeof (struct tty_output) =3D=3D sizeof (ns_output) = in >> my case, and let it go? Bloodcurdlingly horrible! I don't even want to >> think about it. > > Why is it a problem to add some dummy buffer to a struct? what's so > horrible about that? The reason is to let ASAN build run without > false positives. Well, for me it's not a false positive. ASAN is absolutely right about it says. We are accessing memory that's not there because we are accessing something of the wrong type. Making the memory the memory appear doesn't change the fact that we are still accessing something as the wrong type. I find that horrible, sorry :-). But it doesn't matter. I have what I posted in my branch, so it doesn't prevent me personally from proceeding. > Alternatively, cannot you tell ASAN in some way that this code is > okay? The docs say clang supports an ottribute for that=20 Disabling Instrumentation with __attribute__((no_sanitize("address"))) Haven'tever used that, though, so I don't know if it works. From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Oct 2024 12:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.172916889322575 (code B ref 73838); Thu, 17 Oct 2024 12:42:02 +0000 Received: (at 73838) by debbugs.gnu.org; 17 Oct 2024 12:41:33 +0000 Received: from localhost ([127.0.0.1]:33676 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1Pol-0005rw-Kb for submit@debbugs.gnu.org; Thu, 17 Oct 2024 08:41:32 -0400 Received: from mail-wm1-f43.google.com ([209.85.128.43]:56630) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1Pog-0005rk-4X for 73838@debbugs.gnu.org; Thu, 17 Oct 2024 08:41:26 -0400 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4315e62afe0so3093065e9.1 for <73838@debbugs.gnu.org>; Thu, 17 Oct 2024 05:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729168800; x=1729773600; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=qrhEPBJ3rwAQ8pRi9AULeXq5nEdyYMRIAh5vtLfeFYY=; b=gYelBntynYXEsIYVMWbHhi05SfGyCY0+LOEf1dz0RGM7zxahYHLl84OnHrJIkNRXQr bvBRMad6s8S+h2jFLyFMEzzkO/kk1LyNg4cDLZx9HC/LMoKciaifhGF4jIxgUiipE4wF +Nymy8ykJ4pFxerEMOgtdX4ftvycTFMsWEhGDYm1mNGuWDza408sHDCNQxF1Udvd1oVo i2fkc3bOiKn8XKqDzeBhZ9J7SC5s0KBs4c93lQvmHSJ4Dg3s4ZsxD01fuoWw+xl0oCGP oBXLU6OSNhzfCadmw+0AQxTQmzMUPC+iyUvspm3f3vQ4OmnTd6YPoBzgHXHeNi4M3yAY szkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729168800; x=1729773600; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=qrhEPBJ3rwAQ8pRi9AULeXq5nEdyYMRIAh5vtLfeFYY=; b=G4bz0QWRrRqrvuYqjO8gbwtFS4iQ5njY+GT+xYmhIOUHexkH39d8KuX/76hszwvWwU CQHwr8ucg7aXRyqOAnEsbIjiJLiRwgsaNjmRgCvbUhdLQD2yLkfsJ2iIwNbX05igrHke V9cGTGDt1vkXir4sylbRupvq12YWrzaneB7WbfUN4PWHM9Wc/kRUIfT2l0p743q5Ijl5 vh4x7PjzS71i5qzet5GtT+pWmMLzV/gVHDp86COOgV3boy07En48y4IZkp838THtZZ4l wPxTr3x8u4rOkmAigsIQXXqMdNTdF0LBz1sk+HSkmR+ysoym6o2qOLM8XrireXPIridL fTqA== X-Gm-Message-State: AOJu0YyQs30psGleNpKAX43sgDEU+yJ/zj9q6YFm0rn6ZDcUOKsbxB9z pNlAT4yFE3/N+pMs7iamP+FrDrk+eK2garN3IdT4EoHeC6r5dBnmsN0kug== X-Google-Smtp-Source: AGHT+IHGLgPF1Udk+ix7O6UvAYJcPZYniHkwgixG6BQSyfNYme5MgYGoA8bhTMsZYhJgQWG8r4A7ZQ== X-Received: by 2002:a05:600c:3487:b0:431:46fe:4cad with SMTP id 5b1f17b1804b1-4314a2b4cb1mr57997085e9.9.1729168799695; Thu, 17 Oct 2024 05:39:59 -0700 (PDT) Received: from pro2 (pd9e36829.dip0.t-ipconnect.de. [217.227.104.41]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43158c3dedfsm24889975e9.26.2024.10.17.05.39.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Oct 2024 05:39:59 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: <865xprovli.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 17 Oct 2024 13:46:33 +0300") References: <86r08goy76.fsf@gnu.org> <86msj3q4t0.fsf@gnu.org> <86iktrpe46.fsf@gnu.org> <86cyjzp9dj.fsf@gnu.org> <865xprovli.fsf@gnu.org> Date: Thu, 17 Oct 2024 14:39:58 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: 73838@debbugs.gnu.org >> Date: Thu, 17 Oct 2024 09:03:13 +0200 >>=20 >> The immediate problem I'm facing is with tty child frames and >> xterm-mouse: I'm opening a buffer selection child frame (consult-buffer) >> and choose a candidate with a mouse click. The candidates are >> mouse-highlighted. Result is eventually an endless loop in >> process_mark_stack in the non-MPS GC. (Not using the mouse works just >> fine.) > > If you can show the details of that, i.e. step through the loop one > time until it gets to the same point, maybe someone could have an > idea. It's probably something pretty strange: I built with ASAN, no MPS but my workaround for the hightlighting, and get an error: GC marks char-code-property-alist (staticpro), and hits a char-table object that is somehow broken. pdumper-object-p says yes for it, but when checking the mark bit of that char-table with pdumper_marked_p_impl, ASAN complains about an access outside of the bitset being used for the pdumper mark bits. (Not sure if that's already the loop I see without ASAN.) Didn't get further than that today. LLDB decided to crash as well at some point. I'm a bit out of ideas how to find out what's up with that char-table. Maybe I'll wait a bit until I have an idea how I could find that out. From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Oct 2024 03:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.172930990824275 (code B ref 73838); Sat, 19 Oct 2024 03:52:01 +0000 Received: (at 73838) by debbugs.gnu.org; 19 Oct 2024 03:51:48 +0000 Received: from localhost ([127.0.0.1]:40782 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t20VH-0006JS-Lg for submit@debbugs.gnu.org; Fri, 18 Oct 2024 23:51:48 -0400 Received: from mail-wm1-f46.google.com ([209.85.128.46]:43360) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t20VF-0006J9-Dn for 73838@debbugs.gnu.org; Fri, 18 Oct 2024 23:51:46 -0400 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-43155afca99so20700955e9.1 for <73838@debbugs.gnu.org>; Fri, 18 Oct 2024 20:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729309815; x=1729914615; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Lw2Lm5b/P5oV0Q2/J68/xitCogakwA5ZYuiHwWJZY5o=; b=MoErWz1iSxjpeU0rx5Ui2kjAem/5QYiwh+EO3PDA7NZn0UZJNA2lDoGUnEVlDk3EAd rRls9R8NQJ00RZTYZmIcOSN64UMXNie8fT9jjAdsA2C3v03bplUFWT49yfDNoAxnZ9u9 OhOPwjedzootQr8pwIROH3DCpZGiQAWIhWwNv8FtdG3ReOgSCoH+ub7ps7+TyQCaAr8r 1Nr4rY4+zR92qdAxzUDgSmC5NyFGoLi1BQNTumM3yvtz28Vh7cj05bKZR9LiLHLGACEk +ra5BtqdPlKjrLQcf6sJ3z1l4f5UqSgv/cBQAJ3wsb4hg+jSTKrsXc2Wi8h93KwCfLQP 1IDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729309815; x=1729914615; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Lw2Lm5b/P5oV0Q2/J68/xitCogakwA5ZYuiHwWJZY5o=; b=iFoCFn1mRh8O2CClRq3JL+JgfiLifuOP20GM/wpJcARg6p2gNXJg8AT3cbyIibChmb C3SyM7BvJztkPBTOjfAKopFdwjGuhdKhBzVRPo4gxCPxuq917C0CHqE0TXcjXh0JwDeD Zssd3/Y6GB6w6Our8J3D2XbslL11FSHYEfmpp6cYjEzIV4ae8h+BXodnOrc0XWfBaRmo sMc5lBRFQ+SvUzN6BXY//zYKi0vaTKk4xTcBs1FUFajkvRpFmtCOevUul7AyOdRkp5UR 5buChxKdSBlvFHG6QcQc0Val0d4nSW6Iys9qFe/WpMgeowsnF572b+xOxScEJvQn3j9W YMPw== X-Gm-Message-State: AOJu0YxY8uR50PuZHjKCxJO8rBEdHNchN6zSZ3U1eA9SHahkfeAhT4pZ u8kxf1YNNpH6DuCxJZuRA/4SPhuFSBVUbyql2CD2XGcWtn2DYszTrNxUag== X-Google-Smtp-Source: AGHT+IHPIbONCJHiTbgsW9RqUD1IxBLwS8lxvv+hYtGPGHerEqUfmtO9aKxX2uT4hgusv0kgPUDCCw== X-Received: by 2002:a5d:4ac9:0:b0:37c:fbb7:5082 with SMTP id ffacd0b85a97d-37ecf0662demr2758865f8f.25.1729309815180; Fri, 18 Oct 2024 20:50:15 -0700 (PDT) Received: from pro2 (pd9e36926.dip0.t-ipconnect.de. [217.227.105.38]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-37ecf0469acsm3378397f8f.25.2024.10.18.20.50.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Oct 2024 20:50:13 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: ("Gerd =?UTF-8?Q?M=C3=B6llmann?="'s message of "Thu, 17 Oct 2024 14:39:58 +0200") References: <86r08goy76.fsf@gnu.org> <86msj3q4t0.fsf@gnu.org> <86iktrpe46.fsf@gnu.org> <86cyjzp9dj.fsf@gnu.org> <865xprovli.fsf@gnu.org> Date: Sat, 19 Oct 2024 05:50:11 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Eli Zaretskii writes: > >>> From: Gerd M=C3=B6llmann >>> Cc: 73838@debbugs.gnu.org >>> Date: Thu, 17 Oct 2024 09:03:13 +0200 >>>=20 >>> The immediate problem I'm facing is with tty child frames and >>> xterm-mouse: I'm opening a buffer selection child frame (consult-buffer) >>> and choose a candidate with a mouse click. The candidates are >>> mouse-highlighted. Result is eventually an endless loop in >>> process_mark_stack in the non-MPS GC. (Not using the mouse works just >>> fine.) >> >> If you can show the details of that, i.e. step through the loop one >> time until it gets to the same point, maybe someone could have an >> idea. > > It's probably something pretty strange: > > I built with ASAN, no MPS but my workaround for the hightlighting, and > get an error: GC marks char-code-property-alist (staticpro), and hits a > char-table object that is somehow broken. pdumper-object-p says yes for > it, but when checking the mark bit of that char-table with > pdumper_marked_p_impl, ASAN complains about an access outside of the > bitset being used for the pdumper mark bits. > > (Not sure if that's already the loop I see without ASAN.) > > Didn't get further than that today. LLDB decided to crash as well at > some point. > > I'm a bit out of ideas how to find out what's up with that char-table. > Maybe I'll wait a bit until I have an idea how I could find that out. FWIW, this is also reproducible in scratch/igc by building it without MPS and with ASAN. '../src/emacs' -batch --no-site-file --no-site-lisp --eval "(setq load-pref= er-newer t byte-compile-warnings 'all)" --eval "(setq org--inhibit-version-= check t)" -f batch-byte-compile gnus/spam.el emacs(33650,0x1f4c0f240) malloc: nano zone abandoned due to inability to re= serve vm space. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: AddressSanitizer: heap-buffer-overflow on address 0x00010408f87c at = pc 0x000100bc9e54 bp 0x00016f8d11b0 sp 0x00016f8d11a8 READ of size 4 at 0x00010408f87c thread T0 #0 0x100bc9e50 in dump_bitset_bit_set_p pdumper.c:5401 #1 0x100bca4ac in pdumper_marked_p_impl pdumper.c:5604 #2 0x100bb6d70 in pdumper_marked_p pdumper.h:239 #3 0x100bb239c in vector_marked_p alloc.c:4436 #4 0x100bb0fec in process_mark_stack alloc.c:7555 #5 0x100baf538 in mark_object alloc.c:7785 #6 0x100bbc0e4 in mark_char_table alloc.c:7234 #7 0x100bb1348 in process_mark_stack alloc.c:7621 #8 0x100baf538 in mark_object alloc.c:7785 #9 0x100bae71c in mark_object_root_visitor alloc.c:6682 #10 0x100bac47c in visit_static_gc_roots alloc.c:6672 #11 0x100bad420 in garbage_collect alloc.c:6895 ... 0x00010408f87c is located 452 bytes after 372408-byte region [0x00010403480= 0,0x00010408f6b8) [1m[0m[1m[35mallocated by thread T0 here:[1m[0m #0 0x1032a0fd0 in calloc+0x9c (libclang_rt.asan_osx_dynamic.dylib:arm64= e+0x54fd0) #1 0x100bcc2b8 in dump_bitsets_init pdumper.c:5376 #2 0x100bcb79c in pdumper_load pdumper.c:6106 #3 0x1009c10b0 in load_pdump emacs.c:980 #4 0x1009bbe50 in main emacs.c:1436 #5 0x19014c270 () From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Oct 2024 08:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.17293248955248 (code B ref 73838); Sat, 19 Oct 2024 08:02:01 +0000 Received: (at 73838) by debbugs.gnu.org; 19 Oct 2024 08:01:35 +0000 Received: from localhost ([127.0.0.1]:41248 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t24P1-0001Ma-5m for submit@debbugs.gnu.org; Sat, 19 Oct 2024 04:01:35 -0400 Received: from mail-wm1-f49.google.com ([209.85.128.49]:43029) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t24Oy-0001ML-EI for 73838@debbugs.gnu.org; Sat, 19 Oct 2024 04:01:33 -0400 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4314c452180so26328715e9.0 for <73838@debbugs.gnu.org>; Sat, 19 Oct 2024 01:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729324803; x=1729929603; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=8TEoHprp9soec4+UIIpM2nYPRVvj3xH/uDBN3x6UmeU=; b=h3n70KLHIpy0A7APVedx6rE/UnRew/2laSOPUAsQ2971YwUdLK8991Fy7FTwbGTu1O 7TWElv5zSMB+wcI9j+cIw0gR3xIUAdJnje59LqAaHkJIfS0vhMSOmfFmMS9AnRLbKtog lr/FHGHFQaFbgBhAosFv/5KGLZr8ZWYpJgU/lbu3LJhNOF1bx+Cm3dkAUe+rvzut6xIo f804f5skYqMFA+Il1cVO7neBKHoABR242YXGTEj6VAq1gFLHHg79CGl36ds0U8RYL7Qn GJer4twUSO1lL13Kc1m3x9cxEdrzW4Un2hcMf+qHeoq2xaZKRV6ZVX9ddj+5//y4IB8B EVSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729324803; x=1729929603; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=8TEoHprp9soec4+UIIpM2nYPRVvj3xH/uDBN3x6UmeU=; b=tz6w3zmoYr17heilC7fsFSzvkVWFvDMSOubetgTsWhmCbN+SAbR5LvnLqnVtTBLQ3w XVsqSwY9nck8ZAgqhVy+MB5+c8x4OZkCjaAJWxkDVwHETl1Btw88amqI0cv/Yur1z2JK +vTKRqQXKZ7f4Zss6445jzswpHoXCBbTTdDdX8SVvGvSmrpeK6iqm7bWuHH0lMlNZ1BT fDTd/jEZZFmuCvK5JrUh5MIobtGMqzP5Be73HTdEcKVeAK2S0SvE11/P5To6V4pMxfoi Nya8G58RYMDpbofi3/TZA/VLclJ4+PMevvy/bhVIfdnGnJ7l/5VNWer09irUAFvMcU2P yVwg== X-Gm-Message-State: AOJu0YwCtiSw6xZfLCtyiggCGEKcbQER2fIVNgyk/Nf4fc59ex3gsvoG 1kMsX6qG1ifqnA+XDuNVxAgrT+6lAeXIXt5jpr4JF98Dj0SLVFnC3NCBMA== X-Google-Smtp-Source: AGHT+IFlfqeUA+FgsusNd4SmBO8TJgk7Bs0jEKDVnAFgPW16Zxhn/aLzv7H7dzAaCnHhJAHmLpff4A== X-Received: by 2002:a5d:4fc8:0:b0:374:adf1:9232 with SMTP id ffacd0b85a97d-37ecf0039a4mr3154127f8f.19.1729324802560; Sat, 19 Oct 2024 01:00:02 -0700 (PDT) Received: from pro2 (pd9e36926.dip0.t-ipconnect.de. [217.227.105.38]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-37ecf06d24dsm3815140f8f.44.2024.10.19.01.00.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 19 Oct 2024 01:00:01 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: ("Gerd =?UTF-8?Q?M=C3=B6llmann?="'s message of "Sat, 19 Oct 2024 05:50:11 +0200") References: <86r08goy76.fsf@gnu.org> <86msj3q4t0.fsf@gnu.org> <86iktrpe46.fsf@gnu.org> <86cyjzp9dj.fsf@gnu.org> <865xprovli.fsf@gnu.org> Date: Sat, 19 Oct 2024 10:00:00 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > FWIW, this is also reproducible in scratch/igc by building it without > MPS and with ASAN. And configuring --with-ns. Does not happen for me --without-ns, which made my bisect try flop. From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Oct 2024 13:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.17295173755243 (code B ref 73838); Mon, 21 Oct 2024 13:30:02 +0000 Received: (at 73838) by debbugs.gnu.org; 21 Oct 2024 13:29:35 +0000 Received: from localhost ([127.0.0.1]:50655 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2sTW-0001MS-80 for submit@debbugs.gnu.org; Mon, 21 Oct 2024 09:29:34 -0400 Received: from mail-ej1-f45.google.com ([209.85.218.45]:48587) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2sTT-0001MI-Ac for 73838@debbugs.gnu.org; Mon, 21 Oct 2024 09:29:32 -0400 Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-a86e9db75b9so582971166b.1 for <73838@debbugs.gnu.org>; Mon, 21 Oct 2024 06:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729517283; x=1730122083; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=hG0TOpHfHw794gIda2qMhA2KvcM5Y1m3PHrvoBdVUSI=; b=dbitYcsM3Uxln8jnoXJtZwu3eS0SlzWfGGakVTUH1dm6H40nhuEvyYQXCKnMjDBhZa jtZc+ePQ5/CmFgJjpUkHJZYi1OryV8BZ0zecOIAoOi7BA3deLScdagiH6+oJC2CwcZtP LI1AKDrS/qg+4W2rLXJm/eFL0YmxPRLcoyTumkYb0ga/eqn2srIYSr9BKkDxmqeFtZzB LGfbYtdy6VzmfvWVTndSmkyAAzaeG8ZXzxjVbRegTpQ4fKcdCVOrjpEHUIO3GIJ9j70I rO3wD5zgKLblIqzGc0DIdkc87KVRlnCo1pG9l/oYNRPLubh9y7jDCNPHcVlTaTZpfaYp Yo4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729517283; x=1730122083; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=hG0TOpHfHw794gIda2qMhA2KvcM5Y1m3PHrvoBdVUSI=; b=sw7Afod27AGOn47CshTB/oJbhl1EnDhbp8pJ3R8uDcuD/3ShZ1TwZO1KehtWjv3g2S dve33nJkK2d/f8f+JA2409O4MHkPZNrSnADu49cmzy7LYlhzT3CPi5ZcH1u98WTiyM8j /CyYp/MqDp2ke8fp+2SlljSS7tL/1CiSpqcjsKtgqOLWh+JWZF77OwQcMHQvaw7gqxoa mzUucij8kiEjgZga2Xga61bMEbXrE+GCUKB27QrJiOoFk5dJhfVAeMZaEwWhGhmfGa3k qhOJl+T9wlmCR/JsuMIUilA4HNv0r/biUF6fRomfZWI84yiRfS0r59Q0kjtD0mvHwZCz W8AQ== X-Gm-Message-State: AOJu0YwDV+RvJwNpY7driEOeFMottYWr4onLj/LsZHtQKCAJm+tp85Sv hiXWgC3BJ2CLsleJhecUpuZBL10r4ihIk9gNKsdv216YeRshwJM0CLBlMw== X-Google-Smtp-Source: AGHT+IHjW3qKjxRZozHB7cdniI8TCXod1Cq28/LOHYR05oaJDf2gUVKSOAqTYlq5zhPsK0eyq/TTlQ== X-Received: by 2002:a17:907:7d92:b0:a99:fd2c:4f06 with SMTP id a640c23a62f3a-a9a69de9dafmr1343388666b.65.1729517282706; Mon, 21 Oct 2024 06:28:02 -0700 (PDT) Received: from pro2 (p4fe3a8c0.dip0.t-ipconnect.de. [79.227.168.192]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9a912d6255sm206815566b.19.2024.10.21.06.28.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Oct 2024 06:28:02 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: ("Gerd =?UTF-8?Q?M=C3=B6llmann?="'s message of "Sat, 19 Oct 2024 10:00:00 +0200") References: <86r08goy76.fsf@gnu.org> <86msj3q4t0.fsf@gnu.org> <86iktrpe46.fsf@gnu.org> <86cyjzp9dj.fsf@gnu.org> <865xprovli.fsf@gnu.org> Date: Mon, 21 Oct 2024 15:28:01 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Gerd M=C3=B6llmann writes: > >> FWIW, this is also reproducible in scratch/igc by building it without >> MPS and with ASAN. > > And configuring --with-ns. Does not happen for me --without-ns, which > made my bisect try flop. FWIW, this was in the end so mysterious that I switched from Xcode's clong 16 to Homebrew LLVM 19.1, and the ASAN error in pdumper.c disappeared. From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Oct 2024 13:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.172951894210582 (code B ref 73838); Mon, 21 Oct 2024 13:56:02 +0000 Received: (at 73838) by debbugs.gnu.org; 21 Oct 2024 13:55:42 +0000 Received: from localhost ([127.0.0.1]:51251 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2ssn-0002kC-QA for submit@debbugs.gnu.org; Mon, 21 Oct 2024 09:55:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44998) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2ssl-0002e0-QC for 73838@debbugs.gnu.org; Mon, 21 Oct 2024 09:55:40 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t2ssF-0004M4-Lj; Mon, 21 Oct 2024 09:55:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=vbStpkRUVBv2QGdTh8GhMXrkPxImHep0M25/N1b+f5k=; b=ISxTC3jH11TQu8Sf2H3R 3f14kkQy04+oIE4v/Esu2yizQ08LVbvasacIEQMsRZtlpk4zN5F2a97A0iV9pI70jx6WNKXgUF2K9 yn+BWZmcwpp+hIxxQlVEWhAZj2igOR2ZpCY3swJaotxYBCUeOSFdg9kbs/9ZRr5O8JWzLwMt+vcMG MixOHu/82E9b4Yqe6r4+XYtlddvOQlFGhrN2SI+bkYkzhhVcNcGxhsWwk3sRetZe6pil+d+VlKabG gj7K7f/frcbqqPDEevyF7Np5IQhI12VnauVgHQKGHT+Ji4UlorEL2Unim23AK9qsffwWOpfv5GsGW 3QBd/WLVQCP9Rg==; Date: Mon, 21 Oct 2024 16:55:02 +0300 Message-Id: <868quhh87d.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Gerd =?UTF-8?Q?M=C3=B6llmann?= on Mon, 21 Oct 2024 15:28:01 +0200) References: <86r08goy76.fsf@gnu.org> <86msj3q4t0.fsf@gnu.org> <86iktrpe46.fsf@gnu.org> <86cyjzp9dj.fsf@gnu.org> <865xprovli.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: 73838@debbugs.gnu.org > Date: Mon, 21 Oct 2024 15:28:01 +0200 > > Gerd Möllmann writes: > > > Gerd Möllmann writes: > > > >> FWIW, this is also reproducible in scratch/igc by building it without > >> MPS and with ASAN. > > > > And configuring --with-ns. Does not happen for me --without-ns, which > > made my bisect try flop. > > FWIW, this was in the end so mysterious that I switched from Xcode's > clong 16 to Homebrew LLVM 19.1, and the ASAN error in pdumper.c > disappeared. Thanks. So should this bug be closed now? From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Oct 2024 15:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.172952353925313 (code B ref 73838); Mon, 21 Oct 2024 15:13:02 +0000 Received: (at 73838) by debbugs.gnu.org; 21 Oct 2024 15:12:19 +0000 Received: from localhost ([127.0.0.1]:52850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2u4x-0006aD-Eq for submit@debbugs.gnu.org; Mon, 21 Oct 2024 11:12:19 -0400 Received: from mail-ej1-f49.google.com ([209.85.218.49]:53619) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2u4v-0006Zx-C5 for 73838@debbugs.gnu.org; Mon, 21 Oct 2024 11:12:18 -0400 Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a9a977d6cc7so102662666b.3 for <73838@debbugs.gnu.org>; Mon, 21 Oct 2024 08:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729523445; x=1730128245; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=mKqpgiwRhNGv3rb5XpAvRHn3+TqkCVlWhKy4rDA1EeA=; b=Hx9HUddEBWbZQQDP2xCfggxhL3na8x2wvmP64K/XGJrlQ5Dr82hsF3Bv5w8UZ6OwVG kXbNlHU7JE58M5bRZsvZbMaHNalIRydkkSdPrmWvrfV2IOzuWSPJh3LTz2m8ctnnwHij tAPs52v3pq66po0dqYYfua8MZchGgg3f9adCOyimWj1oohJea22Yd8XVW7lUq/eIMT4C cVGhigxF7qJM3PsGcs3IiwmzsvU8VQIjsAEPW15/ohHOYGtM3zGed8K8YYKUW2ul9uCO KFIqs7PgjAQiTxn8qF/8FGz5Imamt4jom2ksdtTHg8f+g+IR0DRvdJphLS03A3aEex0l mAvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729523445; x=1730128245; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=mKqpgiwRhNGv3rb5XpAvRHn3+TqkCVlWhKy4rDA1EeA=; b=oi5xunDbnXR13rfgd4L97P+Lzbkz3QXfikCZrCtN6oRDzb74ruz7vovZuWESUmKod0 2+umvp/rZ7r/ZAZ3UP6nLlSmd0w/ciqkgHEG6mbWNZAP/y/zh5Wo2mXEwrv89sMewgMO BJlh5eqfog+vQ38Z4zfplLkyBb3fMbePAAiGs6isNFnVIGh+AEV/pkalPrW4dtfwZlvo 1Q5DDcGW2/LJqrCaoFJgEjvogEtym6CELEPZKW6Pab28xkwz85aL3glleSAllnowPbLa cR3dJKAix2D/CwssyEbQqSphmIC9nb0jPpYCgm6QSxl8jEVNEpOY5PNrhpd0HHVLG9UN ARNA== X-Gm-Message-State: AOJu0Yxt1wuMMYctZbGKtIQwEF0mEmEy9DmKvvnJZfABSGSZpn/kxqXP +mllz397CTCbgwPHXcJCZ8GCUBDCIljJW92ykFykB4ka/9/hMD9xalXzRw== X-Google-Smtp-Source: AGHT+IH++EeSqZxnFuyewAB++TEiwrP4GrAVGDQQ3pLD3wYP2jo8I596fdgsN4SVRlc1tKVCEZR3gw== X-Received: by 2002:a05:6402:13c8:b0:5cb:728e:926b with SMTP id 4fb4d7f45d1cf-5cb728e9311mr3567837a12.17.1729523444372; Mon, 21 Oct 2024 08:10:44 -0700 (PDT) Received: from pro2 (p4fe3a8c0.dip0.t-ipconnect.de. [79.227.168.192]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5cb66c6b18csm1994633a12.62.2024.10.21.08.10.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Oct 2024 08:10:43 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: <868quhh87d.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 21 Oct 2024 16:55:02 +0300") References: <86r08goy76.fsf@gnu.org> <86msj3q4t0.fsf@gnu.org> <86iktrpe46.fsf@gnu.org> <86cyjzp9dj.fsf@gnu.org> <865xprovli.fsf@gnu.org> <868quhh87d.fsf@gnu.org> Date: Mon, 21 Oct 2024 17:10:42 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: 73838@debbugs.gnu.org >> Date: Mon, 21 Oct 2024 15:28:01 +0200 >>=20 >> Gerd M=C3=B6llmann writes: >>=20 >> > Gerd M=C3=B6llmann writes: >> > >> >> FWIW, this is also reproducible in scratch/igc by building it without >> >> MPS and with ASAN. >> > >> > And configuring --with-ns. Does not happen for me --without-ns, which >> > made my bisect try flop. >>=20 >> FWIW, this was in the end so mysterious that I switched from Xcode's >> clong 16 to Homebrew LLVM 19.1, and the ASAN error in pdumper.c >> disappeared. > > Thanks. So should this bug be closed now? I'll close it in a minute. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 21 11:12:33 2024 Received: (at control) by debbugs.gnu.org; 21 Oct 2024 15:12:33 +0000 Received: from localhost ([127.0.0.1]:52853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2u5A-0006ai-Qa for submit@debbugs.gnu.org; Mon, 21 Oct 2024 11:12:33 -0400 Received: from mail-ej1-f48.google.com ([209.85.218.48]:49282) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2u58-0006aa-PF for control@debbugs.gnu.org; Mon, 21 Oct 2024 11:12:31 -0400 Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-a9a2cdc6f0cso631535866b.2 for ; Mon, 21 Oct 2024 08:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729523463; x=1730128263; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:subject:from:to:message-id :date:from:to:cc:subject:date:message-id:reply-to; bh=oKk5Y+qqXf3hOB8EzcHGFScOBReLYwfoj2YwS1Cr4Ss=; b=AzwNK6w5DNolIpvl26FvM7nXPQPIihX23eCW30lGQyNXplpxhgxH4XgefI9NEFpKtB jD24xLw7/251u2a+Bjwn2mu2UGwwEA3uAbLUXBVphTu5+M0r3C1fCStmgVOr3Rp6OiHu Kpzx3rsF3rHdKhfOgZ/WVOACHPGKe0ToUR9ZZBYuU0NgntsTN/ciwkMiHoLBt+pfAM9v BCG2YxSVRUxr2NpeqALfq8/3QcznZId8CXt/JmgLC8QBxRBnp6BNbdzMtGeaL9/Mzrfz lJpiR6sikcGoFJxK70YS2o+d/oUNUGLUHTQJQ4z+IjpwejRo7o55L2KKKu9sBZDon/dP DrXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729523463; x=1730128263; h=content-transfer-encoding:mime-version:subject:from:to:message-id :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=oKk5Y+qqXf3hOB8EzcHGFScOBReLYwfoj2YwS1Cr4Ss=; b=cnX83JzMhC4J1g1/9pn+htvT3bfyju76mWgMHte0zqn/hwFs2/EuA3MUbKkV06dji2 +bBdRV24KGBu3z/wZgozdjfxQBjT+xSga7thKn3UVw3eamRWyhaqq0kkb7M4bzAIzg+g xYqhsVOmZ0WUUXnNAABAOw2PV8OT61o0FXiURgMORJ9klxvXcQjMUwA+lYOQpKJbmPpQ o1GFsyueovv88sfXNQrvp5mcSHDse41vuiCRaEsOw4yXaHR+rbMEQ35PrqodYim2N29Q lI+Bf8qGcEVBYDgXdZFNLUpfr6U52IP5lnQFMHuLwyBxO/cVuQRu9kGdt5uaqPOMP2ov UErQ== X-Gm-Message-State: AOJu0Yxjy5ficnlJtQOtm66/X3Y0v9T0GrYpcj1C87yQcI5tikbMw6nD gfid0ofwX/1FjAqAi3mvr4Cqey7Bf0L/aSAVCtlwfMhOhKfHLg3aI81/Ww== X-Google-Smtp-Source: AGHT+IFNjTF4/pWGETVJ2nfStLHtJ9ezttSQKzQxm/0vTgHd8zF1DilkCgPgp/zP43vePPcQEZrxSw== X-Received: by 2002:a17:906:7956:b0:a9a:61d:7084 with SMTP id a640c23a62f3a-a9a69c996famr1151409266b.50.1729523462900; Mon, 21 Oct 2024 08:11:02 -0700 (PDT) Received: from pro2 (p4fe3a8c0.dip0.t-ipconnect.de. [79.227.168.192]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9a91370739sm212022866b.109.2024.10.21.08.11.02 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Oct 2024 08:11:02 -0700 (PDT) Date: Mon, 21 Oct 2024 17:11:01 +0200 Message-Id: To: control@debbugs.gnu.org From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Subject: control message for bug #73838 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: close 73838 31.1 quit Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [209.85.218.48 listed in sa-accredit.habeas.com] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gerd.moellmann[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [209.85.218.48 listed in bl.score.senderscore.com] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.218.48 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.218.48 listed in list.dnswl.org] 2.0 MALFORMED_FREEMAIL Bad headers on message from free email service X-Debbugs-Envelope-To: control 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 (+) close 73838 31.1 quit From unknown Thu Jun 19 14:30:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Oct 2024 15:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: 73838@debbugs.gnu.org Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.172952393526728 (code B ref 73838); Mon, 21 Oct 2024 15:19:01 +0000 Received: (at 73838) by debbugs.gnu.org; 21 Oct 2024 15:18:55 +0000 Received: from localhost ([127.0.0.1]:52918 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2uBL-0006wx-FO for submit@debbugs.gnu.org; Mon, 21 Oct 2024 11:18:55 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36956) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2uBH-0006wY-Nr for 73838@debbugs.gnu.org; Mon, 21 Oct 2024 11:18:53 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t2uAl-000504-AH; Mon, 21 Oct 2024 11:18:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=vhzp8xDIQkRPrpL4i+jZI7nJkO++EQ2Uc/DcHmjZq4w=; b=Xqn8D362T3ib+fGZA8Uj Ca32LfgrSkGOl6cY7qEEQvVnZev1JBs/k3x5N2IgIJLLTFQsnDLxS1Ws2ZEUHifbfmbyJUSJI2zSf mGqJUs7NUGT/8YieU5+fSFd7cDI6nC8jm/ZChCuskYxQCFZHV6ITDAncKY6fzLYtLQ3ZLpVoTc8Tw 9DNqhhIXf0C/AUfqJtBzkLPK5Jo0bx2KIyozgMACmTgGIq5yqrVvhAQT0cMTSA9fIsONgtHgs4/ym dCSH9dpu2PVSFOuQ7PZVzvDHXev9omdaaOcofXL0eZcSmcfYVUM2plr7RosM+3iBgAgPxzdbDjkvb SlndAd6YD9hgvg==; Date: Mon, 21 Oct 2024 18:17:42 +0300 Message-Id: <865xplh4dl.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Gerd =?UTF-8?Q?M=C3=B6llmann?= on Mon, 21 Oct 2024 17:10:42 +0200) References: <86r08goy76.fsf@gnu.org> <86msj3q4t0.fsf@gnu.org> <86iktrpe46.fsf@gnu.org> <86cyjzp9dj.fsf@gnu.org> <865xprovli.fsf@gnu.org> <868quhh87d.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: 73838@debbugs.gnu.org > Date: Mon, 21 Oct 2024 17:10:42 +0200 > > Eli Zaretskii writes: > > >> From: Gerd Möllmann > >> Cc: 73838@debbugs.gnu.org > >> Date: Mon, 21 Oct 2024 15:28:01 +0200 > >> > >> Gerd Möllmann writes: > >> > >> > Gerd Möllmann writes: > >> > > >> >> FWIW, this is also reproducible in scratch/igc by building it without > >> >> MPS and with ASAN. > >> > > >> > And configuring --with-ns. Does not happen for me --without-ns, which > >> > made my bisect try flop. > >> > >> FWIW, this was in the end so mysterious that I switched from Xcode's > >> clong 16 to Homebrew LLVM 19.1, and the ASAN error in pdumper.c > >> disappeared. > > > > Thanks. So should this bug be closed now? > > I'll close it in a minute. Thanks!