From: Thiago Melo <tmdmelo@gmail.com>
To: Po Lu <luangruo@yahoo.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 14:06:24 +0000 [thread overview]
Message-ID: <CABpoeKjEq7baqgU+_KUfM7LjpSHY3_iZ=z34k5LcKwegFLm=Zg@mail.gmail.com> (raw)
In-Reply-To: <878rdcu2el.fsf@yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 2288 bytes --]
On Thu, May 25, 2023 at 10:33 AM Po Lu <luangruo@yahoo.com> wrote:
> Did you build with checking?
Yes. Here are the configure options I've been using to test it:
./configure --without-all --with-x-toolkit=no
--without-compress-install --without-tree-sitter --without-json
--with-cairo --enable-checking='yes,glyphs'
--enable-check-lisp-object-type CFLAGS='-O0 -g3'
Let me know if there are relevant settings differences.
> Because when I last tried, this assert
> triggered with the second frame created.
I'm not sure if you tested the last patch I sent as it is, or if you
previously did assert tests on your own with the device returned by
`cairo_xcb_surface_create' at `x_begin_cr_clip'. Assuming it's the
latter, then please pay close attention at this change I made to the
code:
if (cairo_surface_status (surface) == CAIRO_STATUS_SUCCESS)
eassert (FRAME_DISPLAY_INFO (f)->cairo_device
== cairo_surface_get_device (surface));
Notice that, before I do the assert, I first check if the surface
returned by `cairo_xcb_surface_create' is good. One thing that I
observed when debugging is that, every time a new frame is created,
this part of the code is hit 3 times. The first time, the surface it
returns is always a bad one, which might even have some random garbage
value for the device. The other 2 times, it's a proper xcb surface,
and they always have the same device in common. Same thing with
subsequent calls, it's always the same cairo-xcb device. Similar
behavior when I make tooltips appear. I've attached a gdb session log
showing it.
> 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.
Considering my observation above, it doesn't seem that different
_valid_ devices are being created. But if that is really the case and
I'm missing it, then yes, we make a dynamic list of devices instead.
Consider also that, with the changes I proposed, a device reference is
kept from the beginning, which might influence the results here.
[-- Attachment #2: gdb-session--cairo-xcb-device.org --]
[-- Type: application/vnd.lotus-organizer, Size: 5537 bytes --]
next prev parent reply other threads:[~2023-05-25 14:06 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
2023-05-25 14:06 ` Thiago Melo [this message]
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='CABpoeKjEq7baqgU+_KUfM7LjpSHY3_iZ=z34k5LcKwegFLm=Zg@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).