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

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

bug#71289: 30.0.50; cmcheckmagic aborts when tty_write_glyphs writes "Ga


From: Eli Zaretskii
Subject: bug#71289: 30.0.50; cmcheckmagic aborts when tty_write_glyphs writes "Garbage collecting..." in some cases
Date: Mon, 03 Jun 2024 19:21:32 +0300

> From: Daniel Clemente <n142857@gmail.com>
> Date: Mon, 3 Jun 2024 15:35:20 +0000
> Cc: 71289@debbugs.gnu.org
> 
> > So you are saying that the terminal lies to us?  It has 3 rows, but
> > somehow wraps the cursor to the 4th row?  What are the window and
> > frame dimensions at this point?
> 
> I don't know enough to say whether the terminal is providing wrong numbers.
> But it seems that the positions and terminal dimensions aren't wrong, they're 
> just outdated. They were right a
> moment ago (i.e. the terminal was really as large as reported) but I was 
> resizing the window during a slow
> operation (GC) that was trying to display a message due to 
> garbage-collection-messages t, and it seems that
> the GC message is using outdated information about the terminal size. That's 
> my hypothesis.

That hypothesis needs to be explained.  Which is why I asked to
investigate what happens when the SIGWINCH handler is called.

> > What are the window and
> > frame dimensions at this point?
> 
> (I'm using the example mentioned above: 13, vs. 4 - 1). 
> The frame seems 4 lines 80 columns.
> I'm not sure how to obtain the window dimensions from gdb, since there are 
> several fields. Here are two
> attempts to get it, but total_cols/total_lines are 0 so it seems I'm not 
> looking at the right fields.

We determine the actual dimensions of the frame in the SIGWINCH
handler, and the new dimensions are recorded by the signal handler in
f->new_width and f->new_height, see change_frame_size_1.





reply via email to

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