> Date: Thu, 5 Sep 2024 16:45:52 +0200 > Cc: n142...@gmail.com, 73...@debbugs.gnu.org > From: martin rudalics <rudal...@gmx.at> > > >> If so, then this violation might be caused by the fact that we > >> (1) did resize windows according to the new sizes but (2) did not update > >> the frame sizes accordingly. > > > > Can you elaborate on how this could be possible? I always thought we > > first allocate the frame matrices, and then the window matrices (by > > suballocating them from the frame matrices). Am I mistaken? > > But if glyph_row_slice_p (window_row, frame_row) fails, something else > must have invalidated that. I made that change here more than three > years ago and I can neither remember whether an assertion violation made > me do it or a crash nor why I did chose a term like "congruent" in the > comment.
I agree with the theory that the frame matrices were reallocated whereas the window matrices weren't, or the other way around. I just don't understand how it could have happened, given the code we have. I noticed that causing this assertion to fail is not very easy. For example, if I drag the terminal emulator window one line at a time, I can never cause it, even if I get to frame sizes that are much smaller than the minimum we need for 2 windows. Somehow, I need to drag the frame so it resizes by several lines and/or columns. Not sure why. > One possibility I cannot exclude is that adjust_frame_size tries to > resize windows, that step (silently) fails in window_resize_check, the > old values stay in place but the new frame sizes are applied by > adjust_frame_size. But precisely this scenario cannot be healed by my > patch so it's unlikely that it was the cause for the problem I > experienced back then. What is supposed to happen, with the current code, when the frame is resized to less than the minimum dimensions we allow? Shouldn't we disallow/refuse such resizes? And if we don't refuse, what will happen to the windows? E.g., if the frame is not tall enough to show the menu bar, the two mode lines, the mini-window, and at least one line for each of the two windows, what should I expect to see on display? > > Moving code in adjust_frame_glyphs could affect the assertion if the > > assertion was being hit while adjust_frame_glyphs is still being > > executed. But that is not the case, so I don't understand how moving > > some code in adjust_frame_glyphs without changing it could affect the > > assertion violation. I'm probably missing something. > > I'm still too dense to understand what "Moving code" and "moving some > code" could mean in this context. If you have enough patience left, > please elaborate. Taking some code and moving it to another place in the same function can only affect what's going on in that function and the functions it calls. For example, if you had foo (); bar (); baz (); and then you move the call to baz to be before the call to bar, like this: foo (); baz (); bar (); then I can understand why bar and its subroutines are affected. But once we are done with this code, all the 3 calls have been made, and the order in which they were made can hardly matter for the code which runs after that, right? So if the crash was inside the call to bar, then I could understand how moving the call to baz before it could affect the crash. But the backtrace from the assertion violation didn't show adjust_frame_glyphs anywhere on the call-stack, so I don't understand how simply rearranging code inside adjust_frame_glyphs could change something _outside_ it.
