unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Thiago Melo <tmdmelo@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Po Lu <luangruo@yahoo.com>, 63589@debbugs.gnu.org
Subject: bug#63589: [PATCH] 29.0.91; crash after creating graphical frames via emacsclient when compiled with cairo-xcb
Date: Thu, 25 May 2023 10:24:30 +0000	[thread overview]
Message-ID: <CABpoeKjWLHAsqYiKRMOgGjd1PUgE26+85y+9E5N9tzLTP=MULw@mail.gmail.com> (raw)
In-Reply-To: <83jzwwnatg.fsf@gnu.org>

On Thu, May 25, 2023 at 7:12 AM Eli Zaretskii <eliz@gnu.org> wrote:
> I'm trying to establish if there's anything we could do in the
> cairo-xcb configuration to make the crashes more rare, or even prevent
> them altogether.

Regarding this, before posting at the cairo mailing list, I searched
better their archives to check if this issue was already properly
addressed. I found this:

https://lists.cairographics.org/archives/cairo/2018-November/028791.html

Title: cairo_xcb_surface_create() segfaults on second call with
different xcb info

Where Uli Schlachter (libxcb contributor and main maintainer of
Cairo-XCB nowadays) discusses the issue we're having here, the design
of Cairo-XCB, how to use it with multiple surfaces and after reopening
the display. To highlight, Uli says:

| Cairo has to get quite some information from the X11 server. [...]
|
| [...] querying this all the time would be slow. Thus, cairo caches
| this information. Namely, there is an instance of cairo_device_t. This
| instance is kept around even when all surfaces using this device are
| destroyed. [...]
|
| [...] when you call xcb_disconnect(),
| the cache now contains a dangling pointer. The next call to
| xcb_connect() might very well allocate an xcb_connection_t* with the
| same pointer. Thus, you now get a cache hit even though there is a new
| XCB connection. Bad things happen afterwards

Thus, it doesn't matter if Emacs destroys all cairo-xcb surfaces
before closing the display, the device reference will always linger
around together with all its cairo cache by design. It simply doesn't
work like Cairo-XLib at all.

Then, Uli says:

| If you want to keep the device around for later (i.e. have multiple
| surface using the same device), you can save a pointer via:
|
|   cairo_device_t *device = cairo_device_reference(....);
|
| Now, you have to later call cairo_device_destroy() when you no longer
| need the reference, but you get a pointer to the cairo_device_t
| independent of a cairo xcb surface.
|
| Oh and: You have to finish the device before you call xcb_disconnect().

So, any application that uses Cairo-XCB with multiple surfaces and
wants to reopen displays _must_ save a reference to the device and
_must_ finish + destroy it before closing the display.

With this, here's another try to improve the initial patch, this time
storing the cairo xcb device for the display at `x_term_init':

#+begin_src diff
--- a/src/xterm.h    2023-05-25 09:43:50.943793850 +0200
+++ b/src/xterm.h    2023-05-25 11:32:03.701771148 +0200
@@ -883,6 +883,13 @@ struct x_display_info
      clock, or 0 if unknown (if the difference is legitimately 0,
      server_time_monotonic_p will be true).  */
   int_fast64_t server_time_offset;
+
+#if defined USE_XCB && defined USE_CAIRO_XCB
+  /* Cairo device associated with cairo surfaces in this display.
+     Required for proper cleanup before closing display connection
+     in cairo-xcb builds.  */
+  cairo_device_t *cairo_device;
+#endif
 #endif
 };
#+end_src


#+begin_src diff
--- a/src/xterm.c    2023-05-25 09:37:24.811402435 +0200
+++ b/src/xterm.c    2023-05-25 12:18:06.003572028 +0200
@@ -5806,10 +5806,15 @@ x_begin_cr_clip (struct frame *f, GC gc)
       cairo_surface_t *surface;
 #ifdef USE_CAIRO_XCB_SURFACE
       if (FRAME_DISPLAY_INFO (f)->xcb_visual)
+    {
     surface = cairo_xcb_surface_create (FRAME_DISPLAY_INFO (f)->xcb_connection,
                         (xcb_drawable_t) FRAME_X_RAW_DRAWABLE (f),
                         FRAME_DISPLAY_INFO (f)->xcb_visual,
                         width, height);
+    if (cairo_surface_status (surface) == CAIRO_STATUS_SUCCESS)
+      eassert (FRAME_DISPLAY_INFO (f)->cairo_device
+           == cairo_surface_get_device (surface));
+    }
       else
 #endif
     surface = cairo_xlib_surface_create (FRAME_X_DISPLAY (f),
@@ -30504,6 +30509,27 @@ x_term_init (Lisp_Object display_name, c

   unblock_input ();

+#ifdef USE_CAIRO_XCB_SURFACE
+  /* Store reference to the cairo device for this display, to ensure
+     that it 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)
+    {
+      dpyinfo->cairo_device = cairo_device_reference
(cairo_surface_get_device (surface));
+      cairo_surface_destroy (surface);
+    }
+  XFreePixmap (dpyinfo->display, drawable);
+#endif
+
 #if defined HAVE_XFIXES && defined USE_XCB
   SAFE_FREE ();
 #endif
@@ -30783,6 +30809,17 @@ x_delete_terminal (struct terminal *term
     xim_close_dpy (dpyinfo);
 #endif

+#ifdef USE_CAIRO_XCB_SURFACE
+  /* Ensure that the cairo device is destroyed before closing
+     connection (Bug#63589).  */
+  if (dpyinfo->cairo_device)
+    {
+      cairo_device_finish (dpyinfo->cairo_device);
+      cairo_device_destroy (dpyinfo->cairo_device);
+      dpyinfo->cairo_device = NULL;
+    }
+#endif
+
   /* Normally, the display is available...  */
   if (dpyinfo->display)
     {
#+end_src





  reply	other threads:[~2023-05-25 10:24 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-19 11:17 bug#63589: 29.0.91; crash after creating graphical frames via emacsclient when compiled with cairo-xcb Thiago Melo
2023-05-20  1:46 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-20 11:47   ` Thiago Melo
2023-05-21  0:42     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-21 18:25       ` Thiago Melo
2023-05-20 22:47 ` bug#63589: [PATCH] " Thiago Melo
2023-05-21 13:40   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-21 14:30     ` Eli Zaretskii
2023-05-21 16:10       ` Thiago Melo
2023-05-21 17:42         ` Eli Zaretskii
2023-05-22  0:56           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-22  2:48             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-22 10:59               ` Eli Zaretskii
2023-05-22 11:17                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-22 11:40                   ` Eli Zaretskii
2023-05-22 12:07                     ` Thiago Melo
2023-05-22 13:12                       ` Thiago Melo
2023-05-22 19:21                         ` Thiago Melo
2023-05-23  0:30                           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-23 11:37                             ` Eli Zaretskii
2023-05-23 12:08                               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-23 13:01                                 ` Eli Zaretskii
2023-05-23 13:18                                   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-23 14:20                                     ` Eli Zaretskii
2023-05-24  0:22                                       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-24  2:30                                         ` Eli Zaretskii
2023-05-24  3:13                                           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-24  5:15                                             ` Thiago Melo
2023-05-24 11:07                                               ` Eli Zaretskii
2023-05-24 11:54                                                 ` Thiago Melo
2023-05-24 12:15                                                   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-24 14:16                                                     ` Thiago Melo
2023-05-24 15:44                                                     ` Eli Zaretskii
2023-05-25  0:18                                                       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-25  3:38                                                         ` Eli Zaretskii
2023-05-25  6:08                                                           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-25  7:12                                                             ` Eli Zaretskii
2023-05-25 10:24                                                               ` Thiago Melo [this message]
2023-05-25 10:32                                                                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-25 14:06                                                                   ` Thiago Melo
2023-05-25 18:17                                                                     ` Thiago Melo
2023-05-26  0:59                                                                     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-26  5:06                                                                       ` Thiago Melo
2023-05-26  6:14                                                                       ` Eli Zaretskii
2023-05-25 10:34                                                               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-25 11:33                                                                 ` Eli Zaretskii
2023-05-26  0:23                                                                   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-26  6:10                                                                     ` Eli Zaretskii
2023-05-26  8:01                                                                       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-26  8:34                                                                         ` Eli Zaretskii
2023-05-24 11:01                                             ` Eli Zaretskii
2023-05-21 16:09     ` Thiago Melo
2023-05-22  1:05       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-22  5:23         ` Thiago Melo
2023-05-28  3:10 ` bug#63589: " Andrés Ramírez
2023-05-28  3:34 ` Andrés Ramírez
2023-05-28  5:55   ` Eli Zaretskii
2023-05-29 14:51     ` andrés ramírez
2023-05-28 21:23 ` Thiago Melo
2023-05-29 14:58   ` andrés ramírez
2023-05-29 15:21     ` Thiago Melo
2023-05-29 15:37       ` andrés ramírez
2023-05-29 16:10         ` Thiago Melo
2023-05-29 16:21           ` andrés ramírez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABpoeKjWLHAsqYiKRMOgGjd1PUgE26+85y+9E5N9tzLTP=MULw@mail.gmail.com' \
    --to=tmdmelo@gmail.com \
    --cc=63589@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=luangruo@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).