bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#63589: [PATCH] 29.0.91; crash after creating graphical frames via em


From: Thiago Melo
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

(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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]