From: Thiago Melo <tmdmelo@gmail.com>
To: Po Lu <luangruo@yahoo.com>
Cc: 63589@debbugs.gnu.org
Subject: bug#63589: [PATCH] 29.0.91; crash after creating graphical frames via emacsclient when compiled with cairo-xcb
Date: Sun, 21 May 2023 16:09:40 +0000 [thread overview]
Message-ID: <CABpoeKix_RZquad+Gh2ou=7MHqOM0E7Qr1yA30Oy0Lde09Bc-g@mail.gmail.com> (raw)
In-Reply-To: <871qj9246a.fsf@yahoo.com>
(sorry, forgot to hit reply all)
> I would like to know the details of the X error that caused the display
> connection to be closed in the first place
I'm happy to contribute, but I'm sorry that I might not have much time
to do it right now. :(
We can do it slowly, but just in case I'm not around, I'm leaving here
one way to trigger this bug more automatically. After starting emacs
(compiled with cairo-xcb) in daemon mode, the bug can be triggered via
a shell script like this:
```
# some elisp code to close all graphical frames
ELISP="(mapcar (lambda (x) (when (frame-parameter x 'display)
(delete-frame x))) (frame-list))"
# repeatedly create graphical frames and close them all
for k in $(seq 10); do
emacsclient -c -n -a /bin/false &&
sleep 1 &&
emacsclient -e "${ELISP}"
done
```
In any case, I'll reply you about the errors in the other message in
this thread, if you don't mind.
> this change is too large for
> the release branch, but we may be able to fix the X error.
No problem. At least, I wanted to point out one potential direction
for the solution. By the way, I've done my FSF Copyright assignment
already.
> Also, please keep in mind that our policy is to place a space between
> the function identifier and the opening paren of its parameter list in
> function calls
Thank you, I'll keep it in mind.
> and that the device should probably be destroyed even if
> the display no longer exists
It's puzzling, isn't it? The cairo dev also said it should be
destroyed, but that sometimes it doesn't happen for cairo-xcb when (1)
there's a leak somewhere or (2) during some non-leak cases they didn't
specify.
> which usually happens when
> x_delete_terminal is called in response to an IO error.
Here is one thing that I'd like to be clarified about: it seems to me
that you don't expect the display to be closed, as you mentioned
before:
> However,
> this crash happens when a display connection is closed, which is not
> common in normal use. As the backtraces you attached show, an unrelated
> X error is what caused a connection to be closed.
The thing is, with an emacs daemon, after I close the last graphical
frame, x_delete_terminal is always called and the display is always
closed. It happens no matter if I build it with or without cairo, with
errors or without errors.
So I probably misunderstood something here, please do let me know if I
did. Or these things only happens with my computer. I also would love
to know if anyone else is able to replicate this issue.
next prev parent reply other threads:[~2023-05-21 16:09 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
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 [this message]
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='CABpoeKix_RZquad+Gh2ou=7MHqOM0E7Qr1yA30Oy0Lde09Bc-g@mail.gmail.com' \
--to=tmdmelo@gmail.com \
--cc=63589@debbugs.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).