From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#60144: 30.0.50; PGTK Emacs crashes after signal Date: Sun, 18 Dec 2022 19:34:33 +0200 Message-ID: <835ye8fweu.fsf@gnu.org> References: <87edsxfop0.fsf@yahoo.com> <83359dgt7v.fsf@gnu.org> <87a63lfcz7.fsf@yahoo.com> <83y1r5f6lh.fsf@gnu.org> <875ye9f385.fsf@yahoo.com> <83fsddey48.fsf@gnu.org> <871qowgbay.fsf@yahoo.com> <83bko0gact.fsf@gnu.org> <87wn6oesfx.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21623"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 60144@debbugs.gnu.org, karl@karlotness.com To: Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 18 18:35:26 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p6xZN-0005O6-E9 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 18 Dec 2022 18:35:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p6xZ2-0004lP-A5; Sun, 18 Dec 2022 12:35:04 -0500 Original-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 1p6xZ1-0004lH-EC for bug-gnu-emacs@gnu.org; Sun, 18 Dec 2022 12:35:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p6xZ0-0005sD-TO for bug-gnu-emacs@gnu.org; Sun, 18 Dec 2022 12:35:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p6xZ0-0002HX-Dp for bug-gnu-emacs@gnu.org; Sun, 18 Dec 2022 12:35:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 18 Dec 2022 17:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60144 X-GNU-PR-Package: emacs Original-Received: via spool by 60144-submit@debbugs.gnu.org id=B60144.16713848748753 (code B ref 60144); Sun, 18 Dec 2022 17:35:02 +0000 Original-Received: (at 60144) by debbugs.gnu.org; 18 Dec 2022 17:34:34 +0000 Original-Received: from localhost ([127.0.0.1]:35026 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p6xYX-0002H7-El for submit@debbugs.gnu.org; Sun, 18 Dec 2022 12:34:34 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:57476) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p6xYV-0002Gz-IP for 60144@debbugs.gnu.org; Sun, 18 Dec 2022 12:34:32 -0500 Original-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 1p6xYQ-0005on-3J; Sun, 18 Dec 2022 12:34:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=svN18oxjDgvM1+c5n/Jv15OHSEyaCKDxO04JLIjjrMQ=; b=aMyn+/Y7xurT ap8EXIUWtxbPmYN2hOE5Z94LJdJxePb3EdwJ1h3GK+BXghWbof0ee5msxk7jBuBQBrFGCSgF7TCSu SIFlQfw5Pcvp362iDDBCcsHN88pQh3y09SQnW/kkMD2Izzv8ryyJTl4YFhKBqrzM1HeJ+98C9FB9Y 5MmoxVMdtByvI0Uqc7s7dZpDZ+SsKMS7F10AwWIUZpL62z6qmoVAOUM89ajC4n0zh/YBFGIonhqHE zzW9xhdh2uJYrXWPyJ/+oNJJPAbzlftCUxyiC9PMGfORhyPMQg1gTHrtZ4sMtJBCZcZt4DhQRUYrZ qPwTq4yj6V1smJ9y0GENWg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p6xYP-0004Zr-Ij; Sun, 18 Dec 2022 12:34:25 -0500 In-Reply-To: <87wn6oesfx.fsf@yahoo.com> (message from Po Lu on Sun, 18 Dec 2022 21:45:38 +0800) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:251373 Archived-At: > From: Po Lu > Cc: karl@karlotness.com, 60144@debbugs.gnu.org > Date: Sun, 18 Dec 2022 21:45:38 +0800 > > Eli Zaretskii writes: > > >> That code has problems signalling errors, unless it is okay for > >> unblock_input to signal. > > > > I don't understand this part. Why and how is unblock_input part of > > the picture? > > Because unblock_input can call process_pending_signals, and in doing so > handle_async_input, which calls gobble_input (and thus the > read_socket_hook.) As a result, it is not safe for any read_socket_hook > to signal as long as it is not ok for unblock_input to signal as well. But AFAIK it is _always_ safe for unblock_input to signal. When do you think it isn't? > > So in the X/GTK build we have the same problem as with PGTK? If so, > > why not change that as well, to work as I described, i.e. enqueue > > events to our own event queue, which we will then read and process in > > safe context? > > > > AFAIU, w32 already works like that. Does it not? > > It doesn't, see how w32_note_mouse_movement is called from > w32_read_socket. ??? w32_read_socket runs in the Lisp (a.k.a. "main") thread. So it is safe for any code it calls it to signal errors and do anything else it's safe to do for the Lisp machine. > > Yes, understood. But it just tells me that we need to change the > > architecture so that the events delivered by the window-system are not > > processed in callbacks we install to be called by the window-system, > > they should be processed in our own safe context. > > The problem is note_mouse_highlight is simply not supposed to signal. You cannot request that. note_mouse_highlight examines properties, and that can always signal, because properties are Lisp creatures and can invoke Lisp. > It is a function called directly while handling async input as far back > as Emacs 19, much like expose_frame. (IIRC back then there was a > slightly different implementation in each of the *term.c files.) We did a lot of dangerous stuff in Emacs 19, including (oh horror!) reading input and doing redisplay inside signal handlers. We gradually removed all those unsafe parts, and nowadays we only do the minimum in such contexts. If unsafe processing of input is still with us, we should move to safer techniques. That this unsafe code exists for such a long time is therefore not a justification for it to continue existing. Also, I think this unsafe processing of events only happens with GTK/PGTK; other X configurations call XTread_socket and handle_one_xevent from keyboard.c, in a "safe" context. > Moving note_mouse_highlight out of handle_one_xevent would lead to other > bugs, since mouse movement must be processed in order wrt to other X > events. I didn't say we shouldn't process mouse movements. I said that this processing should be limited to generating an Emacs input event and queuing it, will all the pertinent information for further processing. For example, note_mouse_highlight does just three things: . redisplays portion of the window in a special face . changes the way the cursor is drawn . shows help-echo All of that can be done given an input event read by terminals read_socket_hook inside keyboard.c, provided that the information about the mouse move is stored in the input event. There's absolutely no reason to produce the above 3 effects right where we are fed the raw X or GTK event from the window-system or the toolkit. > For example, if an XI_Motion event arrives and is queued, and > then a subsequent XI_Leave event arrives before that event has a chance > to be processed ``in our own safe context'', note_mouse_highlight will > be called after the mouse has left the frame, leading to stuck mouse > highlight. AFAIU, these two events will both be queued, and will both be processed, so there will be not "suck mouse highlight". So I still don't understand what is it that I'm missing that makes you say this safe processing of window-system events is impossible. Anyway, this bug report is not the proper place to discuss this. Please start a discussion on emacs-devel, and let's pick this up there.