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: Thu, 6 Jun 2024 12:36:41 +0000

I'm trying your new code (including the delete_terminals part), thanks.

I just posted a reproduction step for BT2, in another thread here.

I'll try to repeat the other backtraces.

I'm working on many crashes and redisplay bugs at the same time and
they're piling up, and it's getting messy, sorry.

I've seen a new redisplay issue but I can't pinpoint yet where did it
come from, or to which bug it's related.
In rare cases, not only the Emacs frame doesn't use the full size of
the terminal (after resizing the X window) (I consider this to be bug
71343), but also:
- it won't correct itself even after a keypress. I still see the black areas
- the text becomes garbled, e.g. the current line (the line I'm
editing) appears below the cursor, and the situation affects new
frames too, and the solution is to restart Emacs

I can handle it as part of 71343, which I'm still researching.



On Wed, 5 Jun 2024 at 16:43, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > Date: Wed, 05 Jun 2024 18:06:49 +0300
> > From: Eli Zaretskii <eliz <at> gnu.org>
> > Cc: 71289 <at> debbugs.gnu.org
> >
> > > From: Daniel Clemente <n142857 <at> gmail.com>
> > > Date: Wed, 5 Jun 2024 13:50:48 +0000
> > > Cc: 71289 <at> debbugs.gnu.org
> > >
> > > With it (running on 799f78a92c6c31f4d181390523b83d036020ede1 with no
> > > other changes), I still see the same types of crash that I already
> > > reported: in tty_write_glyphs (see BT1 below) and in
> > > build_frame_matrix_from_leaf_window (see BT2 below).
> > > However they don't mention GC now.
> >
> > So it is not exactly the same type of crash.
> >
> > In what scenario does this happen now?  IOW, what did you do to
> > trigger those crashes?
> >
> > I'd like to ask you to run that scenario with a watchpoint on the
> > variable delayed_size_change, and the following two watchpoint
> > commands:
> >
> >   bt 5
> >   continue
> >
> > I hope the backtraces produced by this will explain who resets the
> > delayed_size_change flag, seemingly prematurely(?), and might suggest
> > ideas for a solution.  (I have an idea already, but would like to see
> > some data to make sure the idea is solid.)
>
> I decided to go with my idea anyway, so please update from Git before
> trying next, and if the problem is still there, try answering my
> questions above.
>
> Thanks.

Previous Next

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