Frame resizing causes a crash

Frame resizing causes a crash

[Riku Saikkonen]

I found an odd bug related to resizing an Emacs frame when there are
several windows inside it. Resizing a particular window configuration
to a smaller height causes a crash in text mode, and strange behaviour
in an X window.

I use GNU Emacs 21, and this seems to happen both in GNU/Linux and in
Solaris. I tried these three Emacsen, and they all have the bug:
 - GNU Emacs 21.1.1 (sparc-sun-solaris2.8, X toolkit) of 2002-01-31 on vernal
 - GNU Emacs 21.2.1 (i386-redhat-linux-gnu, X toolkit, Xaw3d scroll bars)
   of 2002-04-09 on porky.devel.redhat.com
 - GNU Emacs 21.2.1 (i386-debian-linux-gnu, X toolkit, Xaw3d scroll bars)
   of 2002-03-22 on raven, modified by Debian

To reproduce the bug:

1. Start a copy of Emacs, and resize it to 80x58 characters.

2. Execute the following Lisp code, and use M-x my-set-windows. (This
   produces three windows, one of which is only 4 lines high.)

   (defun my-set-windows ()
     (interactive)
     (delete-other-windows)
     (split-window-vertically)
     (set-window-text-height nil 4)
     (other-window 1)
     (split-window-vertically))

3. Resize the Emacs frame to 80x24 characters.

When I do this in a text-mode Emacs (inside an xterm), it immediately
crashes with the message:
Fatal error (6).Aborted

When running Emacs in an X window, the bug doesn't crash Emacs, but
causes some very strange behaviour on the display: Emacs shows the
text as if there were several windows, but there is only one mode
line. Moving around and using C-l reveals that there are several
windows, but they seem to overrlap. C-x o jumps between two windows,
and from moving around in them, it appears that the upper one occupies
lines 1-12 in the 24-line display and the lower one uses lines 8-19
(so both are 12 lines high - the text area is 19 lines long in a
window with geometry 80x24 using the default menu and tool bars).
Thus, the mode line of the upper window is displayed on the 13th line,
but often gets overwritten by redrawing of the lower window.

The same kind of bug appears to happen on other window sizes, and also
if I resize the windows manually (using C-x ^ or the mouse on the mode
lines) to a similar configuration. But not all configurations of three
windows produce the bug; it appears that the problem is related to
sizing a very small window to an even smaller size when the frame is
made much smaller.

A backtrace from a core dump generated by the Emacs 21.2.1 on the
Debian GNU/Linux system does not appear helpful:

(gdb) bt
#0  0x40305781 in kill () from /lib/libc.so.6
#1  0x080ce1db in XMapRaised ()
#2  0x403056b8 in sigaction () from /lib/libc.so.6
#3  0x080926d3 in XMapRaised ()
#4  0x080942e1 in XMapRaised ()
#5  0x08055620 in XMapRaised ()
#6  0x08054ebb in XMapRaised ()
#7  0x08052c80 in XMapRaised ()
#8  0x0806670c in XMapRaised ()
#9  0x08066b0a in XMapRaised ()
#10 0x0814dc97 in error ()
#11 0x08056b43 in XMapRaised ()
#12 0x080d2523 in abort ()
#13 0x080d8a33 in abort ()
#14 0x080d0bf4 in abort ()
#15 0x08121dc9 in re_compile_pattern ()
#16 0x080d07d8 in abort ()
#17 0x0812195d in re_compile_pattern ()
#18 0x080d0787 in abort ()
#19 0x080d0301 in abort ()
#20 0x080d0430 in abort ()
#21 0x080cf39f in abort ()
#22 0x402f514f in __libc_start_main () from /lib/libc.so.6
(gdb) q

-- 
-=- Rjs -=- rjs@cs.hut.fi, Riku.Saikkonen@hut.fi
"Or there maybe 'tis cloudless night / and swaying beeches bear
the Elven-stars as jewels white / amid their branching hair."
    -- J.R.R. Tolkien

Re: Frame resizing causes a crash

[Riku Saikkonen]

Hi,

I reported the following bug here about a week ago, but haven't heard
anything on it since. Could someone try to reproduce the bug, so that
I know that it's not only my Emacsen that are at fault? In particular,
it would be nice to know if the current CVS version has this bug...

rjs@cs.hut.fi (Riku Saikkonen) writes:
>I found an odd bug related to resizing an Emacs frame when there are
>several windows inside it. Resizing a particular window configuration
>to a smaller height causes a crash in text mode, and strange behaviour
>in an X window.
>
>I use GNU Emacs 21, and this seems to happen both in GNU/Linux and in
>Solaris. I tried these three Emacsen, and they all have the bug:
> - GNU Emacs 21.1.1 (sparc-sun-solaris2.8, X toolkit) of 2002-01-31 on vernal
> - GNU Emacs 21.2.1 (i386-redhat-linux-gnu, X toolkit, Xaw3d scroll bars)
>   of 2002-04-09 on porky.devel.redhat.com
> - GNU Emacs 21.2.1 (i386-debian-linux-gnu, X toolkit, Xaw3d scroll bars)
>   of 2002-03-22 on raven, modified by Debian
>
>To reproduce the bug:
>
>1. Start a copy of Emacs, and resize it to 80x58 characters.
>
>2. Execute the following Lisp code, and use M-x my-set-windows. (This
>   produces three windows, one of which is only 4 lines high.)
>
>   (defun my-set-windows ()
>     (interactive)
>     (delete-other-windows)
>     (split-window-vertically)
>     (set-window-text-height nil 4)
>     (other-window 1)
>     (split-window-vertically))
>
>3. Resize the Emacs frame to 80x24 characters.
>
>When I do this in a text-mode Emacs (inside an xterm), it immediately
>crashes with the message:
>Fatal error (6).Aborted
>
>When running Emacs in an X window, the bug doesn't crash Emacs, but
>causes some very strange behaviour on the display: Emacs shows the
>text as if there were several windows, but there is only one mode
>line. Moving around and using C-l reveals that there are several
>windows, but they seem to overrlap. C-x o jumps between two windows,
>and from moving around in them, it appears that the upper one occupies
>lines 1-12 in the 24-line display and the lower one uses lines 8-19
>(so both are 12 lines high - the text area is 19 lines long in a
>window with geometry 80x24 using the default menu and tool bars).
>Thus, the mode line of the upper window is displayed on the 13th line,
>but often gets overwritten by redrawing of the lower window.
>
>The same kind of bug appears to happen on other window sizes, and also
>if I resize the windows manually (using C-x ^ or the mouse on the mode
>lines) to a similar configuration. But not all configurations of three
>windows produce the bug; it appears that the problem is related to
>sizing a very small window to an even smaller size when the frame is
>made much smaller.
>
>A backtrace from a core dump generated by the Emacs 21.2.1 on the
>Debian GNU/Linux system does not appear helpful:
>
>(gdb) bt
>#0  0x40305781 in kill () from /lib/libc.so.6
>#1  0x080ce1db in XMapRaised ()
>#2  0x403056b8 in sigaction () from /lib/libc.so.6
>#3  0x080926d3 in XMapRaised ()
>#4  0x080942e1 in XMapRaised ()
>#5  0x08055620 in XMapRaised ()
>#6  0x08054ebb in XMapRaised ()
>#7  0x08052c80 in XMapRaised ()
>#8  0x0806670c in XMapRaised ()
>#9  0x08066b0a in XMapRaised ()
>#10 0x0814dc97 in error ()
>#11 0x08056b43 in XMapRaised ()
>#12 0x080d2523 in abort ()
>#13 0x080d8a33 in abort ()
>#14 0x080d0bf4 in abort ()
>#15 0x08121dc9 in re_compile_pattern ()
>#16 0x080d07d8 in abort ()
>#17 0x0812195d in re_compile_pattern ()
>#18 0x080d0787 in abort ()
>#19 0x080d0301 in abort ()
>#20 0x080d0430 in abort ()
>#21 0x080cf39f in abort ()
>#22 0x402f514f in __libc_start_main () from /lib/libc.so.6
>(gdb) q

-- 
-=- Rjs -=- rjs@cs.hut.fi, Riku.Saikkonen@hut.fi
"Or there maybe 'tis cloudless night / and swaying beeches bear
the Elven-stars as jewels white / amid their branching hair."
    -- J.R.R. Tolkien

Re: Frame resizing causes a crash

[Lute Kamstra]

rjs@cs.hut.fi (Riku Saikkonen) writes:

> I reported the following bug here about a week ago, but haven't heard
> anything on it since. Could someone try to reproduce the bug, so that
> I know that it's not only my Emacsen that are at fault? In particular,
> it would be nice to know if the current CVS version has this bug...

Thank you for your report.  I used today's CVS (GTK toolkit) and was
able to reproduce the bugs you describe.  I'm not knowledgeable on
redisplay things, though.  So we just have to wait until one of the
redisplay hackers has time to work on this.

  Lute.

> rjs@cs.hut.fi (Riku Saikkonen) writes:
>>I found an odd bug related to resizing an Emacs frame when there are
>>several windows inside it. Resizing a particular window configuration
>>to a smaller height causes a crash in text mode, and strange behaviour
>>in an X window.
>>
>>I use GNU Emacs 21, and this seems to happen both in GNU/Linux and in
>>Solaris. I tried these three Emacsen, and they all have the bug:
>> - GNU Emacs 21.1.1 (sparc-sun-solaris2.8, X toolkit) of 2002-01-31 on vernal
>> - GNU Emacs 21.2.1 (i386-redhat-linux-gnu, X toolkit, Xaw3d scroll bars)
>>   of 2002-04-09 on porky.devel.redhat.com
>> - GNU Emacs 21.2.1 (i386-debian-linux-gnu, X toolkit, Xaw3d scroll bars)
>>   of 2002-03-22 on raven, modified by Debian
>>
>>To reproduce the bug:
>>
>>1. Start a copy of Emacs, and resize it to 80x58 characters.
>>
>>2. Execute the following Lisp code, and use M-x my-set-windows. (This
>>   produces three windows, one of which is only 4 lines high.)
>>
>>   (defun my-set-windows ()
>>     (interactive)
>>     (delete-other-windows)
>>     (split-window-vertically)
>>     (set-window-text-height nil 4)
>>     (other-window 1)
>>     (split-window-vertically))
>>
>>3. Resize the Emacs frame to 80x24 characters.
>>
>>When I do this in a text-mode Emacs (inside an xterm), it immediately
>>crashes with the message:
>>Fatal error (6).Aborted
>>
>>When running Emacs in an X window, the bug doesn't crash Emacs, but
>>causes some very strange behaviour on the display: Emacs shows the
>>text as if there were several windows, but there is only one mode
>>line. Moving around and using C-l reveals that there are several
>>windows, but they seem to overrlap. C-x o jumps between two windows,
>>and from moving around in them, it appears that the upper one occupies
>>lines 1-12 in the 24-line display and the lower one uses lines 8-19
>>(so both are 12 lines high - the text area is 19 lines long in a
>>window with geometry 80x24 using the default menu and tool bars).
>>Thus, the mode line of the upper window is displayed on the 13th line,
>>but often gets overwritten by redrawing of the lower window.
>>
>>The same kind of bug appears to happen on other window sizes, and also
>>if I resize the windows manually (using C-x ^ or the mouse on the mode
>>lines) to a similar configuration. But not all configurations of three
>>windows produce the bug; it appears that the problem is related to
>>sizing a very small window to an even smaller size when the frame is
>>made much smaller.
>>
>>A backtrace from a core dump generated by the Emacs 21.2.1 on the
>>Debian GNU/Linux system does not appear helpful:
>>
>>(gdb) bt
>>#0  0x40305781 in kill () from /lib/libc.so.6
>>#1  0x080ce1db in XMapRaised ()
>>#2  0x403056b8 in sigaction () from /lib/libc.so.6
>>#3  0x080926d3 in XMapRaised ()
>>#4  0x080942e1 in XMapRaised ()
>>#5  0x08055620 in XMapRaised ()
>>#6  0x08054ebb in XMapRaised ()
>>#7  0x08052c80 in XMapRaised ()
>>#8  0x0806670c in XMapRaised ()
>>#9  0x08066b0a in XMapRaised ()
>>#10 0x0814dc97 in error ()
>>#11 0x08056b43 in XMapRaised ()
>>#12 0x080d2523 in abort ()
>>#13 0x080d8a33 in abort ()
>>#14 0x080d0bf4 in abort ()
>>#15 0x08121dc9 in re_compile_pattern ()
>>#16 0x080d07d8 in abort ()
>>#17 0x0812195d in re_compile_pattern ()
>>#18 0x080d0787 in abort ()
>>#19 0x080d0301 in abort ()
>>#20 0x080d0430 in abort ()
>>#21 0x080cf39f in abort ()
>>#22 0x402f514f in __libc_start_main () from /lib/libc.so.6
>>(gdb) q
>
> -- 
> -=- Rjs -=- rjs@cs.hut.fi, Riku.Saikkonen@hut.fi
> "Or there maybe 'tis cloudless night / and swaying beeches bear
> the Elven-stars as jewels white / amid their branching hair."
>     -- J.R.R. Tolkien

Re: Frame resizing causes a crash

[Jan D.]

> rjs@cs.hut.fi (Riku Saikkonen) writes:
> 
> > I reported the following bug here about a week ago, but haven't heard
> > anything on it since. Could someone try to reproduce the bug, so that
> > I know that it's not only my Emacsen that are at fault? In particular,
> > it would be nice to know if the current CVS version has this bug...
> 
> Thank you for your report.  I used today's CVS (GTK toolkit) and was
> able to reproduce the bugs you describe.  I'm not knowledgeable on
> redisplay things, though.  So we just have to wait until one of the
> redisplay hackers has time to work on this.
> 

I've added a new function to calculate window sizes when a frame
shrinks.  There was a bug in that small windows at the top was
resized to a negative value (that means delete this window).  The
negative value is then used to calculate the position of the next window
which is why there was confusion.  Also, when a window was deleted because
it would be too small, the amount of resize needed was not distributed
among the other windows, so the remaining windows where too big for the
frame.  In this example, Emacs needed to shrink all windows 11 lines,
but the smallest one atop was only 4.  So instead of shrinking 11*3 +
1 reminder = 34, we got 4 + 11*2 + 1 reminder = 27.

Anyway, the new implementation tries to keep the number of windows intact
as long as possible, shrinking larger windows instead until we really
need to delete a window.  Please try this version and see if it looks OK.
BTW, this is in CVS head only.

Thanks,

	Jan D.

Re: Frame resizing causes a crash

[Lute Kamstra]

"Jan D." <jan.h.d@swipnet.se> writes:

>> rjs@cs.hut.fi (Riku Saikkonen) writes:
>> 
>>> I reported the following bug here about a week ago, but haven't
>>> heard anything on it since. Could someone try to reproduce the
>>> bug, so that I know that it's not only my Emacsen that are at
>>> fault? In particular, it would be nice to know if the current CVS
>>> version has this bug...
>> 
>> Thank you for your report.  I used today's CVS (GTK toolkit) and
>> was able to reproduce the bugs you describe.  I'm not knowledgeable
>> on redisplay things, though.  So we just have to wait until one of
>> the redisplay hackers has time to work on this.
>
> I've added a new function to calculate window sizes when a frame
> shrinks.  There was a bug in that small windows at the top was
> resized to a negative value (that means delete this window).  The
> negative value is then used to calculate the position of the next
> window which is why there was confusion.  Also, when a window was
> deleted because it would be too small, the amount of resize needed
> was not distributed among the other windows, so the remaining
> windows where too big for the frame.  In this example, Emacs needed
> to shrink all windows 11 lines, but the smallest one atop was only
> 4.  So instead of shrinking 11*3 + 1 reminder = 34, we got 4 + 11*2
> + 1 reminder = 27.
>
> Anyway, the new implementation tries to keep the number of windows
> intact as long as possible, shrinking larger windows instead until
> we really need to delete a window.  Please try this version and see
> if it looks OK.  BTW, this is in CVS head only.

Your change fixes the problems that Riku Saikkonen describes.  Thanks.

  Lute.