all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.





  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.