From: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Thiago Melo <tmdmelo@gmail.com>
Cc: 63589@debbugs.gnu.org, Eli Zaretskii <eliz@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 18:32:50 +0800 [thread overview]
Message-ID: <878rdcu2el.fsf@yahoo.com> (raw)
In-Reply-To: <CABpoeKjWLHAsqYiKRMOgGjd1PUgE26+85y+9E5N9tzLTP=MULw@mail.gmail.com> (Thiago Melo's message of "Thu, 25 May 2023 10:24:30 +0000")
Thiago Melo <tmdmelo@gmail.com> writes:
> 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));
Did you build with checking? Because when I last tried, this assert
triggered with the second frame created.
> + }
> 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
If we are going down this route, I think we should save each distinct
device returned by `cairo_surface_get_device', and delete each of them
upon the terminal being deleted.
As I explained, I saw that function return different devices for the
same XCB connection, which is definitely a problem with Cairo.
But again, that's a hack. I would rather just disable this misdesigned
and buggy interface by default.
next prev parent reply other threads:[~2023-05-25 10:32 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
2023-05-25 10:32 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878rdcu2el.fsf@yahoo.com \
--to=bug-gnu-emacs@gnu.org \
--cc=63589@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=luangruo@yahoo.com \
--cc=tmdmelo@gmail.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.