From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: bug#60144: 30.0.50; PGTK Emacs crashes after signal Date: Tue, 20 Dec 2022 09:39:13 +0800 Message-ID: <87cz8eetvi.fsf@yahoo.com> 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> <835ye8fweu.fsf@gnu.org> <87sfhcdulj.fsf@yahoo.com> <838rj3ea07.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30589"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 20 02:40:31 2022 Return-path: Envelope-to: ged-emacs-devel@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 1p7RcM-0007hQ-9d for ged-emacs-devel@m.gmane-mx.org; Tue, 20 Dec 2022 02:40:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p7RbS-0007uI-Rk; Mon, 19 Dec 2022 20:39:34 -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 1p7RbQ-0007u8-VT for emacs-devel@gnu.org; Mon, 19 Dec 2022 20:39:33 -0500 Original-Received: from sonic314-21.consmr.mail.ne1.yahoo.com ([66.163.189.147]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p7RbO-0002ih-2o for emacs-devel@gnu.org; Mon, 19 Dec 2022 20:39:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671500366; bh=mcgj0GvK7ByGFBWTB73qJSQJFbl1z8uOUrw9DRGL2Vw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=HnMkNVliHbH1jgTlif0/W+SK7adSEMPgmbf2nk6nRPmlqvbCDlGlfqqxhsxvWy6y7tTp7vuxeb309cOH3GZCNI9DancPK6t4ktxUkDrr4qDNwWrunG8LfrtnwIs59kzK1sN7kvhYidgTznap4tYJqxgYNW6bFJluZmIva4glDjf181ObNhPw0KrgHeobtcyk43dXk3U59/5BVkO47R88hyfz8gclYkNF1ZgZ1iIr9FZ7HkRPFXp1VFDuVazJTqTxrxDhS0OhVZU84Pp//NSu7I8myOXDjP6pWVOaPnmHLi3eHpfpXaOVTkoGfu25NfFg6VKjvX4pJENXGunS01KEeA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671500366; bh=06aZ7e0tAtGn6C66sgbMQz5ZewSZJMJOI5CEeSNnPmw=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=GpmSeNSAVleC20A3FBOxLSxWcPB8IN/O9w5YBvApEtLz07UIDULjLfUw4xx/2hFDVz7EUKew8RmFzL4emVQYVO1k9kJaDo0ub0WULUZwTxCXweMLVcW7INEMX4ucEC7XXKDDBBjL2IIYN5r9URd1m+VMaxPjmw7+327NFVeG+6MDxx8Gw+dzVNboctmHbOGwynkPh+p5FpR8w4e3krBY4Xe3Nb/uu3fDgADkC6McI02c898S9eSvWwxvNOhE9P7NBBVeYTKr1S2bBNtcMe8TFEDLrmkfixxm/zbixSpfcgXc82X4aE9e87qs2GPZ4DzV6uJn/Uo2+kQ2LzZ48CcfiA== X-YMail-OSG: 4TMryVoVM1kDZLFs6ETDMl5AQdNiQqJmKbsbTB3CMKFrob4lkt0yxts88eS.86S IktrQrClEpdKOLj8Ftdg3Cm7iThboHYUo5NQHUp2HkEEzGZ92odafmtrj7qisJ_9NFWJWzFf60LC hZONTGMf7wGcS8lLRfDaxEn9DOTr0R9Ht7Q2mbBOZhzNy34Aqvqx8crzMKen_9ubMr1i7G5_RMet 0euvKdPHUj98L2jalGD8UX7fLHPBUb0FSvo53bY.s6AteohvcsFcfMZ2mkqD3Js0cLADnmKclPe_ iMESpYV6Y8Gp.qtikIxcx3AKxhTXUun92JSvTjPJnyoNMhreyFnDCEYIM_tF7oFGgxHZyu5aLE3c xzvRgRI8QslkEVu5wrWNFMyDsFQXRdIbtN.kUXub1ovcv_LkgM6QM10RDAh6qvgGiNMyHqM1in37 lN8BebHnbHNsp.oYJyWbSZx3hmKzoXE.PtiiyrUAfPAbn9nY5DXRXoylJfRwj5c4EBcEGwonefnj ujTHmaCdshqj50lyuhabUnRWd5QtEjLbLEbAfdEey8wPEPjKMndg_8q9J6UBgtY8w_5wIz9rSrWX rkuxWXwc3LjtPaGvyM6LYm9L6qh8s1EzrzTgK3TRyWeu0y5puCpXJUxgpN_uCvlmsaW_plFaeP0H 8eSL7Ix4OW41liUpqyT.KIKRCaNnsNwH6pkiNDkXfn2t0ri7ZK2hRIA1l2ZowtWWyxcrEcuM_7Zy FgqMHlPCu6aBSEau0OL4fnzhCYtYwBR1GSIdw0BWMrMwi.0Md.HLyqmPIOGEXbtlvLy2J9mxf1.6 smpOvg7dhKDQbH2LUtHJeEHvgUkkAWR35r690m937S X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Tue, 20 Dec 2022 01:39:26 +0000 Original-Received: by hermes--production-sg3-b666c6484-nr67k (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e702e46a414a38c2eb25ee2663d4c520; Tue, 20 Dec 2022 01:39:18 +0000 (UTC) In-Reply-To: <838rj3ea07.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 19 Dec 2022 16:36:08 +0200") X-Mailer: WebService/1.1.20982 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.189.147; envelope-from=luangruo@yahoo.com; helo=sonic314-21.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:301675 Archived-At: Eli Zaretskii writes: >> From: Po Lu >> Cc: emacs-devel@gnu.org >> Date: Mon, 19 Dec 2022 09:56:40 +0800 >> >> Eli Zaretskii writes: >> >> > But AFAIK it is _always_ safe for unblock_input to signal. When do >> > you think it isn't? >> >> In almost all of the helper functions where it is called: >> tear_down_x_back_buffer, set_up_x_back_buffer, et cetera. > > I don't think I understand why. Let's take tear_down_x_back_buffer, > for example: why isn't it safe to call unblock_input from it? > tear_down_x_back_buffer is called: > > . from x_set_inhibit_double_buffering, which is a frame parameter > handler, so it is only called from the Lisp thread > . from x_free_frame_resources, which AFAIU is only called from the > Lisp thread, when we delete a frame > > So what is the problem here? what am I missing? If unblock_input signals inside, then the double buffering state could be left inconsistent. For example, the back buffer picture could be freed, but the back buffer itself may be left present, which can lead to crashes later on. That it is called from the only thread present does not make it safe. More generally, C code does not expect unblock_input to signal! See this piece of call_process in callproc.c: { if (!specpdl_ref_valid_p (tempfile_index)) record_deleted_pid (pid, Qnil); else { eassert (1 < nargs); record_deleted_pid (pid, args[1]); clear_unwind_protect (tempfile_index); } synch_process_pid = 0; } } unblock_child_signal (&oldset); unblock_input (); <======= if (pid < 0) report_file_errno (CHILD_SETUP_ERROR_DESC, Qnil, child_errno); /* Close our file descriptors, except for callproc_fd[CALLPROC_PIPEREAD] since we will use that to read input from. */ for (i = 0; i < CALLPROC_FDS; i++) if (i != CALLPROC_PIPEREAD && 0 <= callproc_fd[i]) { emacs_close (callproc_fd[i]); callproc_fd[i] = -1; } emacs_close (filefd); clear_unwind_protect (specpdl_ref_add (count, -1)); If unblock_input signals, filefd will not be closed. Or this piece of x_create_bitmap_mask in image.c: pixmap = image_bitmap_pixmap (f, id); width = x_bitmap_width (f, id); height = x_bitmap_height (f, id); block_input (); ximg = XGetImage (FRAME_X_DISPLAY (f), pixmap, 0, 0, width, height, ~0, ZPixmap); if (!ximg) { unblock_input (); return; } result = x_create_x_image_and_pixmap (f, width, height, 1, &mask_img, &mask); unblock_input (); <====================== if (!result) { XDestroyImage (ximg); return; } If unblock_input signals, then ximg (which is potentially a lot of data) leaks. > But unblock_input is only called from the Lisp thread, at least in the > w32 build. And it should only be called from the Lisp thread. It > cannot be safely called from any other thread. Being called from the Lisp thread does not make it safe to signal! Consider the following example code: int fd; char *buffer; fd = emacs_open (...); if (fd == -1) return; buffer = xmalloc (100); block_input (); do_something_with_buffer_and_fd (fd, buffer); unblock_input (); /* more activity. */ close (fd); xfree (buffer); Notice how fd and bufferare not closed if unblock_input signals. Now look at ftcrfont_open: block_input (); pat = ftfont_entity_pattern (entity, pixel_size); FcConfigSubstitute (NULL, pat, FcMatchPattern); FcDefaultSubstitute (pat); match = FcFontMatch (NULL, pat, &result); ftfont_fix_match (pat, match); FcPatternDestroy (pat); font_face = cairo_ft_font_face_create_for_pattern (match); if (!font_face || cairo_font_face_status (font_face) != CAIRO_STATUS_SUCCESS) { unblock_input (); FcPatternDestroy (match); return Qnil; } cairo_matrix_t font_matrix, ctm; cairo_matrix_init_scale (&font_matrix, pixel_size, pixel_size); cairo_matrix_init_identity (&ctm); #ifdef HAVE_PGTK cairo_font_options_t *options = xsettings_get_font_options (); #else cairo_font_options_t *options = cairo_font_options_create (); #endif #ifdef USE_BE_CAIRO if (be_use_subpixel_antialiasing ()) cairo_font_options_set_antialias (options, CAIRO_ANTIALIAS_SUBPIXEL); #endif cairo_scaled_font_t *scaled_font = cairo_scaled_font_create (font_face, &font_matrix, &ctm, options); cairo_font_face_destroy (font_face); cairo_font_options_destroy (options); unblock_input (); If the last unblock_input signals, match (allocated by FcFontMatch) leaks. >> > You cannot request that. note_mouse_highlight examines properties, >> > and that can always signal, because properties are Lisp creatures and >> > can invoke Lisp. >> >> Could you please explain how? > > Which part is unclear? Which properties involve Lisp execution, and why the evaluation of that Lisp cannot be put inside internal_catch_all. > These calls will all have to go, then. Maybe we should use some > simplified, stripped down version of handle_one_xevent, which doesn't > invoke processing that can access Lisp data and the global state. Why > would a toolkit menu widget need to call note_mouse_highlight, which > is _our_ function that implements _our_ features, about which GTK (or > any other toolkit) knows absolutely nothing?? The toolkit menu mostly demands that Emacs set the cursor to the appropriate cursor for whatever the pointer is under. The X server can also demand Emacs expose parts of the frame at any time, due to window configuration changes. > If it's impossible to do safely, it will not work. It already doesn't > work in popup menus on w32, for similar reasons. That's a minor > inconvenience to users, and a much smaller catastrophe than making > these unsafe calls. But it worked since the beginning of 2006 or so, when xmenu.c was made to call handle_one_xevent. Anyway, the "minor inconvenience" can be avoided by simply wrapping note_mouse_highlight in internal_catch_all. Why do you think that would be too harsh? > I don't see how this is related, sorry. You asked: > >> 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. > > And I responded saying that there should be no "mouse stuck" because > both XI_Motion and XI_Leave will be queued and processed in the order > they arrived. What does this have to do with the safety of calling > clear_mouse_face, or lack thereof? > > I'm saying that there's no need to process these events immediately, > when the event calls into the Lisp machine. We can, and in many cases > already do, queue the event and process it a bit later, and in a > different, safer, context. But then as a result the mouse face will not be dismissed when entering a menu. And we will also lose the valuable development feature of using mouse-high to determine how wedged a stuck Emacs really is. > But it's already "in keyboard.c"! See the part that begins with > > /* Try generating a mouse motion event. */ > else if (some_mouse_moved ()) > > which ends with > > if (!NILP (x) && NILP (obj)) > obj = make_lispy_movement (f, bar_window, part, x, y, t); > > Then we process these "lispy movements" as input. That isn't related to mouse-highlight, and only happens when track-mouse is non-nil. track-mouse is nil because it requires calling XTmouse_position on all mouse movement, which is a very expensive operation (with 15 km between me and the X server, it takes 90 milliseconds!) > Not normally, no. But if some Lisp program sets bad text properties > or overlays, it could signal. We can never assume in Emacs that some > Lisp machine code never signals. Then the simple solution would be to catch those signals inside note_mouse_highlight. What could be the problem with that? We could even log the signals to *Messages*, like with-demoted-errors.