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
next prev parent 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).