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: Mon, 22 May 2023 13:12:16 +0000

> > > > What is the kind of situations in which these crashes could happen?
> > >
> > > Precisely that described in this bug report: when displays are closed
> > > and reopened within a short time period.
> >
> > What kind of user-level situations could cause this?  Is invoking
> > emacsclient soon after deleting the last visible frame the only one?
> > And what does "short time period" mean, quantitatively? milliseconds?
> > seconds? minutes?
>
> Sorry, in my experience it seems that the time interval between
> closing the display and opening it again doesn't matter. It seems to
> be more about the amount of times that the display is closed and then
> opened (which is often 3 times for me, for whatever reason).
>
> I'm testing it here again with Xvfb and an automation script, with a
> 10 minutes delay after creating a single graphical frame, and another
> 10 minutes delay after closing it and before creating a new one. I'll
> report the results soon.
>
> Also, this bug seems more likely to happen when emacs is built without
> a toolkit (which is was I've been testing so far), since the display
> is always closed after the last graphical frame is closed. Which made
> me realize, after looking at frame.c, that this bug might as well join
> the family of Bug#5802, Bug#21509, Bug#23499, and Bug#27816.

With 10 minutes intervals, I got the X errors previously mentioned by
the 3rd time the display was opened, and then emacs crashed by the 5th
time the display was opened. So, assuming that 10 minutes is close
enough to infinity, we can say that the time interval doesn't matter.





reply via email to

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