From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#63589: [PATCH] 29.0.91; crash after creating graphical frames via emacsclient when compiled with cairo-xcb Date: Wed, 24 May 2023 20:15:21 +0800 Message-ID: <87v8gisz6u.fsf@yahoo.com> References: <87wn11yyi4.fsf@yahoo.com> <87edn9ytbo.fsf@yahoo.com> <835y8kr5re.fsf@gnu.org> <87pm6sy5rb.fsf@yahoo.com> <83wn10ppa1.fsf@gnu.org> <874jo3yjly.fsf@yahoo.com> <837cszp9cc.fsf@gnu.org> <87cz2rw8pz.fsf@yahoo.com> <83y1lfnqwb.fsf@gnu.org> <87y1lfuqyb.fsf@yahoo.com> <83wn0znn7j.fsf@gnu.org> <87lehevaqz.fsf@yahoo.com> <83r0r6o3zk.fsf@gnu.org> <87edn6v2v3.fsf@yahoo.com> <83h6s2ng1p.fsf@gnu.org> Reply-To: Po Lu Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29403"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 63589@debbugs.gnu.org, Eli Zaretskii To: Thiago Melo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 24 14:16:33 2023 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 1q1nPs-0007Vu-HI for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 May 2023 14:16:32 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q1nPW-0001dO-Jk; Wed, 24 May 2023 08:16:10 -0400 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 1q1nPP-0001d1-6b for bug-gnu-emacs@gnu.org; Wed, 24 May 2023 08:16:04 -0400 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 1q1nPO-00077u-G7 for bug-gnu-emacs@gnu.org; Wed, 24 May 2023 08:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q1nPO-0002qR-2b for bug-gnu-emacs@gnu.org; Wed, 24 May 2023 08:16:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 May 2023 12:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63589 X-GNU-PR-Package: emacs Original-Received: via spool by 63589-submit@debbugs.gnu.org id=B63589.168493053810902 (code B ref 63589); Wed, 24 May 2023 12:16:02 +0000 Original-Received: (at 63589) by debbugs.gnu.org; 24 May 2023 12:15:38 +0000 Original-Received: from localhost ([127.0.0.1]:42551 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q1nP0-0002pm-D9 for submit@debbugs.gnu.org; Wed, 24 May 2023 08:15:38 -0400 Original-Received: from sonic307-56.consmr.mail.ne1.yahoo.com ([66.163.190.31]:40440) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q1nOx-0002pV-Kf for 63589@debbugs.gnu.org; Wed, 24 May 2023 08:15:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684930530; bh=TU42naKL9d5tuX2avgWcnrAMITgOG82MeT+xWINXX4Y=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=nUSW9Tks0JQMYx7qTDatlDE22uvaM6sJZTsTZQ1TjrYGD7fiiQAKzBQ+7QmigBZ04o+pRUXtK0PJEAZFWPepKrdboIs+vUor/gPgY4FziK4XkiTndu+X8qJX0ydfSRodi5YFr5Yy7kYGL8v8dvxSTS8Qm0rg8rRzWTqclxMM5fLlfYpyNKfHmG5O2Z6ZahkzimxiXMQUqId7JXxkh7GCgnX9zEhIKjYFzMssCF9o32MaTywWcGaQVkTLaWBni1ulnyQiNpMzhi3EULjHdePOUPulwKvK/aPM+RuiJvTvETAwP2yZDTw1yo+jNLG2QYspgrnPTmkIV5cQNmbHl10BnQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684930530; bh=LKV9/rIGQxSKsc50jmYmApWll94+iUO3mrz/Md0dfLq=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=sP5xkLC6wy1ybwRJjPGWXrUEadnL47X4i9wzWuZIw1QtucitGdN9bgW2aD1uQGRl0n2uJ4DvHWAxvScqwTV6WRKuhjACHAIQwSoolAQxb/uxmjFzm+rZ6QKYjSJMMaZpqbvV7wpRyfEbBAl0jVk05552ZKDXVUt694pEdBK3+LRmkQ046VfmMhxZAl8PnHq5WSG7g/kQow6a2XXr9hoWYKE3PoYMChPrUAFbyIsjodVE/zh7KzZUHsoq5GvZP9Ae5Tkfn+oYKfa9bQqw60A3Jh1G2QkjHCKGgFQU4Dyu9+sfHKdiVeGUXjfW+uCArgdj+/0KOgY6ow/8/XNaVx9N2w== X-YMail-OSG: cFTO2JIVM1mebw82RREbXPhFY0fnFtQlQ6Hs09KbDbVF53yiox_OZOo6Xo_pQim HQtFWK7PtnKRS6h4FvgggE34RcF7D45IxFoJGtepxEKLCTroz1HQzRyrko2XAizpwqwWifGuyckI TKcQK_dGKOd2UVsLtUhfh34MFWTnLUg.mmHJfjnybdQHzvFl2E6IO6dnPdMee1F8QMxJq6Xgtwwe 5tsm4v8kNDk.DXX0IGPjJBn7lBNrl36_0CQxhZVlRseNPeIi0z7lahjL56C4U8SSOOJ2op99K89C M5AzOKwg0YnoSAZ_dYEZ1ZIP_MJ5gZNPZkesibcefk.dSM0Uy7JrxcqrK1KYdUpOoH01US6a2qkY LNyRrCZ16gVauJx01.JPDSEWN0_s6enR_0y1ZWb6DXF8jhgeIX4uDA_0qzTJ7si7rEew3veOmbmU 7H9ifffeKgyBoiHf2pmahc07kz7JD.fveSzL3m9.wet.z_63xa4n3KAqnA0.qIWIFLqVbBBUyK5O NOa3giHHLOOX7NnEYmX8otm5iHCC6Zg6D10ZfWHtQ_x_HNQ04DFP4OztllDulbh.A9mvznWxMAqI 0UgIC.mlcoRHlWLy7wiCia6V7OFHzCCcSuEKpMZMC8HL_fpZR6iSMBXvnSA_WIUfbxczEcJLHIkp 4e2.0xfdveQtSRov.fFRtxfIPTCeQETKcZoI7xYCSSQWAFajKz_WwlYJGiLm3Sn3VucCvqNy1.4z 1s_Kl5pJomZghhanjmXdPx9l3b28UJERSPYGGoVRZgybgWf0lWn_U4kgpwLMO.KdYDSfP7ymxqYO AUnxJuEFICALbALEKbgT1HNuIsGUkri5W3bXPTRqGQ X-Sonic-MF: X-Sonic-ID: d30567f4-6c0d-48a5-bf79-e1d7917f6d58 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Wed, 24 May 2023 12:15:30 +0000 Original-Received: by hermes--production-sg3-748897c457-fp9l7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a04e27f3c08042c0715df7b0cf4ffdc0; Wed, 24 May 2023 12:15:26 +0000 (UTC) In-Reply-To: (Thiago Melo's message of "Wed, 24 May 2023 11:54:30 +0000") X-Mailer: WebService/1.1.21495 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo 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:262293 Archived-At: Thiago Melo writes: > Sorry for not being clear. I meant calls to `delete-terminal', when > Emacs is built with Cairo-XCB, and regardless of the toolkit. It's a > similar scenario to trigger the bug: launch Emacs daemon, open one or > more graphical frames, call the elisp function`delete-terminal' (all > graphical frames and the display are closed because of it), open a new > graphical frame... > > My last patch doesn't fix it because it only works when > `(delete-frame)' is called instead. This situation is specific for > toolkitless + Cairo-XCB Emacs, since here it ends up calling > `x_delete_terminal' -> `XCloseDisplay'. Other toolkits don't call > `x_delete_terminal' here, due to the logic at `delete_frame'. > > I hope I was more clear this time. > > My opinion is that it's all the same issue, which boils down to > Cairo-XCB requiring more manual memory management than Cairo-XLib by > design or limitation. I think we should really consider the approach > from my first patch, which is ensuring that the Cairo-XCB device is > cleaned up before calling XCloseDisplay. Everything else is a > workaround. If the patch is considered too unsafe or too big, then we > must clarify the specifics of what makes it so, so the matter can be > addressed in a better way. I thought I explained what the problems with trying to fix this in Emacs are. The first is: there's a reference leak in Cairo somewhere, since Emacs never allows displays to be closed without each frame being destroyed, and destroying each frame will also dereference its Cairo surface; thus, it's not actually Emacs's problem. > Here's another patch, similar to the first one, but it only acts at > `x_delete_terminal', and without storing global references. The > strategy is similar to the one used at > `ftcrfont_get_default_font_options'. It creates a dummy pixmap, then a > dummy cairo xcb surface from it, then it extracts the cairo device > from the surface, and then cleans up them all. > > #+begin_src diff > --- a/src/xterm.c 2023-05-24 12:42:14.873824624 +0200 > +++ b/src/xterm.c 2023-05-24 13:45:23.798382193 +0200 > @@ -30841,6 +30841,30 @@ > closing all the displays. */ > XrmDestroyDatabase (dpyinfo->rdb); > #endif > +#ifdef USE_CAIRO_XCB_SURFACE > + /* Ensure that the cairo device is destroyed before closing > + connection (Bug#63589). For that, we create a drawable, an XCB > + surface for that drawable, and then we get the device reference > + from there. */ > + > + Pixmap drawable; > + cairo_surface_t *surface; > + > + drawable = XCreatePixmap (dpyinfo->display, dpyinfo->root_window, > + 1, 1, dpyinfo->n_planes); > + surface = cairo_xcb_surface_create (dpyinfo->xcb_connection, drawable, > + dpyinfo->xcb_visual, 1, 1); > + > + if (cairo_surface_status (surface) == CAIRO_STATUS_SUCCESS) > + { > + cairo_device_t *cairo_device; > + cairo_device = cairo_device_reference (cairo_surface_get_device > (surface)); > + cairo_surface_destroy (surface); > + cairo_device_finish (cairo_device); > + cairo_device_destroy (cairo_device); > + } > + XFreePixmap (dpyinfo->display, drawable); > +#endif > #ifdef USE_GTK > xg_display_close (dpyinfo->display); > #else > #+end_src The other problem occurs when `cairo_xcb_surface_create' creates a different device from the one that was previously created for the display. So you have only destroyed one of several devices, any one of which may rear its ugly head later. This is also a bug in Cairo. BTW, it's not necessary to call XFreePixmap, as all resources created by the client will be destroyed per the close down mode set earlier. Thanks.