GNU bug report logs - #71289
30.0.50; cmcheckmagic aborts when tty_write_glyphs writes "Garbage collecting..." in some cases

Previous Next

Full log

View this message in rfc822 format

From: Daniel Clemente <n142857 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71289 <at> debbugs.gnu.org
Subject: bug#71289: 30.0.50; cmcheckmagic aborts when tty_write_glyphs writes "Garbage collecting..." in some cases
Date: Mon, 3 Jun 2024 15:56:17 +0000

[Message part 1 (text/plain, inline)]

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


On Fri, 31 May 2024 at 18:27, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Daniel Clemente <n142857 <at> gmail.com>
> > Date: Fri, 31 May 2024 17:09:29 +0000
> > Cc: Eli Zaretskii <eliz <at> gnu.org>
> >
> > While playing with resizing the urxvt terminal size (X window), I
> > found other bugs where Emacs doesn't know the real size of the
> > terminal, or becomes unsynchronized with the actual terminal size.
> > This may cause many of the other bugs I've seen (things in the style
> > of: the GC message wants to use 2 minibuffer lines because it thinks
> > there are 2 lines, but actually there's just 1, etc.).
> >
> > The two resizing bugs I found (but I don't have time to research them
> > in detail yet) are:
> > - if the X terminal has 4 visible rows, FrameRows(tty) reports 4. If
> > 3, then 3. But if it has 2 or 1 rows, Emacs still sees 3. And editing
> > is garbled
> > - if I decrease the terminal size fast, e.g. 81→71→61→51→41→31→21→11→1
> > lines, often Emacs doesn't notice all changes, and it may still report
> > that FrameRows(tty) is e.g. 31 when it went further down to 1
> > (31→21→11→1)
> >
> > - in addition there's a more complex refresh bug (not about resizing I
> > think), in which the next frame I focus after having killed a frame
> > won't be refreshed (e.g. I can resize the X window and it doesn't
> > notice, new sections appear black) until I press a key or move the
> > mouse. It's 100% reproducible but I need to research this better
> > because it involves window managers and X
> >
> > However I didn't see a direct crash from these issues. But maybe a GC
> > message in some of these conditions can cause the alert.
> >
> > I may report them as separate bugs but in a while; I'm reporting too
> > many TTY bugs and too fast; I need time for other things.
> >
> > I also saw a new type of TTY+GC error (not sure if it's the same issue
> > as this bug):
>
> Please investigate what happens with our SIGWINCH handler (in
> dispnew.c) in these cases.
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.