bug#71289: 30.0.50; cmcheckmagic aborts when tty_write_glyphs writes "Garbage collecting..." in some cases

[Daniel Clemente]

> Bug#71343 seems to describe a GUI frame (if not, what does the
> window-manager have to do with it?).  While here we are talking about
> TTY frames, right?  And killing frames is not involved in this bug
> report, right?  Or what am I missing?

This one (bug 71289) seems to be about crashes involving GC messages
and resizing the terminal.
I don't know the root cause; it could be some bug in the redisplay code.
I started thinking about other redisplay bugs and filed bug#71343, but
that one isn't related to this bug because it's not about GC. The
other 2 issues I mentioned may or not be related, I don't know.

In all reports I'm using TTY frames, i.e. Emacs compiled without X
support; it's not GUI frames.  But I'm running them inside a urxvt
window in X with a window manager.  I wanted a simpler and smaller
Emacs without any X support, but I still run it in X.

Killing frames is not involved or necessary for the current bug report (#71289).

On Mon, 3 Jun 2024 at 16:03, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Daniel Clemente <n142857@gmail.com>
> > Date: Mon, 3 Jun 2024 15:56:17 +0000
> > Cc: 71289@debbugs.gnu.org
> >
> > > Please investigate what happens with our SIGWINCH handler (in
> > > dispnew.c) in these cases.
> >
> > In the case mentioned above, in which: after killing a frame and resizing 
> > another one, new sections appear
> > black.
> > I reported it as bug #71343, since it's not related to GC like this bug.
>
> I'm not sure I understand: is this related to this bug in some way?
>
> Bug#71343 seems to describe a GUI frame (if not, what does the
> window-manager have to do with it?).  While here we are talking about
> TTY frames, right?  And killing frames is not involved in this bug
> report, right?  Or what am I missing?