GNU bug report logs - #18422
24.3.93; Assertion violation when resizing mini-window on a TTY

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 18422 <at> debbugs.gnu.org
Subject: bug#18422: 24.3.93; Assertion violation when resizing mini-window on a TTY
Date: Wed, 10 Sep 2014 20:33:26 +0300

> Date: Wed, 10 Sep 2014 10:03:27 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 18422 <at> debbugs.gnu.org
> 
>  > I already tried this before reporting the bug.  It doesn't work,
>  > because we then hit these assertions in fake_current_matrices:
>  >
>  > 	  eassert (m->matrix_h == WINDOW_TOTAL_LINES (w));
>  > 	  eassert (m->matrix_w == WINDOW_TOTAL_COLS (w));
> 
> We would have to use pixel sizes there too and maybe elsewhere.

Like I said: I don't think it's a good idea to give up on keeping the
"total" members valid at all times.

>  > In general, I think it's a bad idea to have bogus values in
>  > WINDOW_TOTAL_LINES and WINDOW_TOTAL_COLS, they are not documented to
>  > be invalid under any circumstances, so the code relies on them.
> 
> Agreed.  The "total" values are bogus from the moment a function like
> `resize-mini-window-internal' is executed until `window--pixel-to-total'
> is executed.  Unfortunately, I currently adjust the frame glyphs right
> in between.  I should either move the adjust_frame_glyphs call to
> Fwindow_resize_apply_total or set the new total sizes before calling
> window_resize_apply and have the latter call window_resize_apply_total.

Please do one or the other, I don't think we can leave the release
branch in its current state.  It's all too easy to trigger this
problem.

>  > What exactly frightens you in your first proposal?  Perhaps we should
>  > install my patch on the emacs-24 branch and your window.el patch on
>  > the trunk?
> 
> I'm afraid that the current bug is only the tip of an iceberg.  We
> should close the window of vulnerability sketched above.  On the
> emacs-24 branch.  Neither of the two schemes from the previous paragraph
> is entirely trivial so using pixel values instead of character values
> would put us more on the safe side.

I think the iceberg whose tip you envision includes the invalidity of
the "total" values.  IOW, this is imaginary safety, more bugs are
lurking out there.

> Eventually, I intend to remove the total_lines/total_cols fields from
> the frame structure and have FRAME_TOTAL_COLS and FRAME_TOTAL_LINES
> calculate the values directly from the pixel sizes.  I refrained from
> doing this already because I'm never sure how these values should get
> rounded.

That might be a good plan, but it' not for the release branch.

Previous Next

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