bug#61704: 29.0.60; Crash in get_narrowed_begv

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

I just got the following crash:

#0  0x00007f43164b0e7c in __pthread_kill_implementation () at /lib64/libc.so.6
#1  0x00007f4316460aa6 in raise () at /lib64/libc.so.6
#2  0x000000000041dd7d in terminate_due_to_signal (sig=sig@entry=8, backtrace_limit=backtrace_limit@entry=40) at emacs.c:464
#3  0x000000000041e244 in handle_fatal_signal (sig=sig@entry=8) at sysdep.c:1783
#4  0x000000000055f118 in deliver_thread_signal (sig=8, handler=0x41e239 <handle_fatal_signal>) at sysdep.c:1775
#5  0x000000000055f1f9 in deliver_fatal_thread_signal (sig=<optimized out>) at sysdep.c:1795
#6  0x00007f4316460b50 in <signal handler called> () at /lib64/libc.so.6
#7  0x0000000000453617 in get_narrowed_begv (w=<optimized out>, pos=13523) at xdisp.c:3519
#8  0x0000000000456ee5 in reseat (it=0x7ffc4e7ed560, pos=..., force_p=<optimized out>) at xdisp.c:7468
#9  0x00000000004574fb in init_iterator (it=<optimized out>, w=<optimized out>, charpos=<optimized out>, bytepos=<optimized out>, row=<optimized out>, base_face_id=<optimized out>) at xdisp.c:3488
#10 0x000000000045cac2 in start_display (it=it@entry=0x7ffc4e7ed560, w=w@entry=0xef69700, pos=...) at xdisp.c:3595
#11 0x000000000046bc16 in try_window (window=window@entry=0xef69705, pos=..., flags=flags@entry=1) at xdisp.c:20561
#12 0x000000000048abb8 in redisplay_window (window=<optimized out>, just_this_one_p=<optimized out>) at xdisp.c:19953
#13 0x000000000048d65b in redisplay_window_0 (window=window@entry=0xef69705) at xdisp.c:17439
#14 0x00000000005cac14 in internal_condition_case_1 (bfun=bfun@entry=0x48d630 <redisplay_window_0>, arg=arg@entry=0xef69705, handlers=<optimized out>, hfun=hfun@entry=0x444e20 <redisplay_window_error>) at eval.c:1498
#15 0x0000000000442254 in redisplay_windows (window=0xef69705) at xdisp.c:17409
#16 0x0000000000442275 in redisplay_windows (window=0x5649ac75) at xdisp.c:17403
#17 0x00000000004755db in redisplay_internal () at xdisp.c:16863
#18 0x000000000054ef03 in read_char (commandflag=1, map=0x20219f93, prev_event=0x0, used_mouse_menu=0x7ffc4e7f2bcb, end_time=0x0) at keyboard.c:2627
#19 0x0000000000551bc5 in read_key_sequence (keybuf=<optimized out>, prompt=0x0, dont_downcase_last=<optimized out>, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:10074
#20 0x0000000000553a67 in command_loop_1 () at keyboard.c:1376
#21 0x00000000005cab87 in internal_condition_case (bfun=bfun@entry=0x5538c0 <command_loop_1>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x547210 <cmd_error>) at eval.c:1474
#22 0x000000000053fc4a in command_loop_2 (handlers=handlers@entry=0x90) at keyboard.c:1125
#23 0x00000000005caae1 in internal_catch (tag=tag@entry=0xff30, func=func@entry=0x53fc30 <command_loop_2>, arg=arg@entry=0x90) at eval.c:1197
#24 0x000000000053fbef in command_loop () at keyboard.c:1103
#25 0x0000000000546dc1 in recursive_edit_1 () at keyboard.c:712
#26 0x000000000054713e in Frecursive_edit () at keyboard.c:795
#27 0x00000000004264c2 in main (argc=<optimized out>, argv=<optimized out>) at emacs.c:2529

The cause is an arithmetic trap in get_narrowed_begv:

  return max ((pos / len - 1) * len, BEGV);

where len is 0.  The window was previously being resized, and has a
pixel width of 24.


In GNU Emacs 29.0.60 (build 1, x86_64-pc-linux-gnu) of 2022-12-24 built
 on trinity
Repository revision: 0e39ad6fa56d50b4710157f0b6f396e492da0dfb
Repository branch: HEAD
Windowing system distributor 'The X.Org Foundation', version 11.0.12101099
System Description: Fedora Linux 37 (Workstation Edition)

Configured using:
 'configure --with-native-compilation --with-x-toolkit=no
 --without-cairo --without-tree-sitter'

Configured features:
ACL DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LCMS2
LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
OLDXMENU PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF WEBP X11
XDBE XFT XIM XINPUT2 XPM ZLIB

Important settings:
  value of $LANG: en_GB.utf8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Messages

Minor modes in effect:
  electric-pair-mode: t
  desktop-save-mode: t
  global-telega-mnz-mode: t
  telega-root-auto-fill-mode: t
  telega-active-locations-mode: t
  telega-patrons-mode: t
  display-time-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  lost-selection-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Gregory Heytings]

>
> The cause is an arithmetic trap in get_narrowed_begv:
>
> return max ((pos / len - 1) * len, BEGV);
>
> where len is 0.  The window was previously being resized, and has a 
> pixel width of 24.
>

How can len possibly be 0 at that point?  It is (in short) 
window_body_width (w, WINDOW_BODY_IN_CANONICAL_CHARS) * window_body_height 
(w, WINDOW_BODY_IN_CANONICAL_CHARS).  We could add a condition in 
get_narrowed_len to return 1 when the result is 0, but it could be a bug 
somewhere else (can a window body have a zero width and/or height?), in 
which case it would be better to fix the bug there.

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Eli Zaretskii]

> Date: Wed, 22 Feb 2023 20:20:02 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> The cause is an arithmetic trap in get_narrowed_begv:
> 
>   return max ((pos / len - 1) * len, BEGV);
> 
> where len is 0.  The window was previously being resized, and has a
> pixel width of 24.

How do you get such windows?  I thought we never allowed windows that
are so small.

Anyway, I installed a possible fix on the emacs-29 branch, please see
if it solves this.

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Eli Zaretskii]

> Cc: 61704@debbugs.gnu.org
> Date: Wed, 22 Feb 2023 12:48:02 +0000
> From: Gregory Heytings <gregory@heytings.org>
> 
> 
> > The cause is an arithmetic trap in get_narrowed_begv:
> >
> > return max ((pos / len - 1) * len, BEGV);
> >
> > where len is 0.  The window was previously being resized, and has a 
> > pixel width of 24.
> >
> 
> How can len possibly be 0 at that point?  It is (in short) 
> window_body_width (w, WINDOW_BODY_IN_CANONICAL_CHARS) * window_body_height 
> (w, WINDOW_BODY_IN_CANONICAL_CHARS).  We could add a condition in 
> get_narrowed_len to return 1 when the result is 0, but it could be a bug 
> somewhere else (can a window body have a zero width and/or height?), in 
> which case it would be better to fix the bug there.

I agree that we should understand how this happened (and asked a
similar question), but I installed a defensive protection anyway.  It
cannot do any harm.

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> How can len possibly be 0 at that point?  It is (in short) 

Because the pixel width of W is less than its frame's column width.
The division performed window_body_width is truncating, i.e:

  24 / 25 = 0

and I suspect the actual width being divded at that point is less than
w->pixel_width, since that window had fringes.

>> window_body_width (w, WINDOW_BODY_IN_CANONICAL_CHARS) * window_body_height 
>> (w, WINDOW_BODY_IN_CANONICAL_CHARS).  We could add a condition in 
>> get_narrowed_len to return 1 when the result is 0, but it could be a bug 
>> somewhere else (can a window body have a zero width and/or height?), in 
>> which case it would be better to fix the bug there.
>
> I agree that we should understand how this happened (and asked a
> similar question), but I installed a defensive protection anyway.  It
> cannot do any harm.

I did say that this happened while resizing the window.  It was being
displayed in an ediff-created frame.

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Gregory Heytings]

>> How can len possibly be 0 at that point?  It is (in short) 
>> window_body_width (w, WINDOW_BODY_IN_CANONICAL_CHARS) * 
>> window_body_height (w, WINDOW_BODY_IN_CANONICAL_CHARS).  We could add a 
>> condition in get_narrowed_len to return 1 when the result is 0, but it 
>> could be a bug somewhere else (can a window body have a zero width 
>> and/or height?), in which case it would be better to fix the bug there.
>
> I agree that we should understand how this happened (and asked a similar 
> question), but I installed a defensive protection anyway.  It cannot do 
> any harm.
>

Okay.  Let's hope this will not hide another real bug.

I found a way to get such small windows: set window-min-width, 
window-min-height, window-safe-min-width and window-safe-min-heigth to 0. 
Of course doing that ignores the fact that the docstring of the 
window-safe-min-* variables say that "Anything less might crash Emacs", 
and that their values are 2 (width) and 1 (height).  Which makes me wonder 
why these variables can be changed / exist.

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> How do you get such windows?  I thought we never allowed windows that
> are so small.

I tried resizing an ediff frame.

> Anyway, I installed a possible fix on the emacs-29 branch, please see
> if it solves this.

We'll have to wait another 30 days to find out, I guess, because that
was my uptime up to this point.  Resizing the ediff popup no longer
crashes.

Thanks.

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Gregory Heytings]

>>> How can len possibly be 0 at that point?  It is (in short)
>
> Because the pixel width of W is less than its frame's column width. The 
> division performed window_body_width is truncating, i.e:
>
>  24 / 25 = 0
>
> and I suspect the actual width being divded at that point is less than 
> w->pixel_width, since that window had fringes.
>

In that case it's a bug in window_body_width I guess, which should do

/* Don't return a non-positive value.  */
return max (width / denom, 1);

>
> I did say that this happened while resizing the window.  It was being 
> displayed in an ediff-created frame.
>

You mean, the ediff popup control frame?

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Eli Zaretskii]

> Date: Wed, 22 Feb 2023 13:17:27 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: luangruo@yahoo.com, 61704@debbugs.gnu.org
> 
> 
> >> How can len possibly be 0 at that point?  It is (in short) 
> >> window_body_width (w, WINDOW_BODY_IN_CANONICAL_CHARS) * 
> >> window_body_height (w, WINDOW_BODY_IN_CANONICAL_CHARS).  We could add a 
> >> condition in get_narrowed_len to return 1 when the result is 0, but it 
> >> could be a bug somewhere else (can a window body have a zero width 
> >> and/or height?), in which case it would be better to fix the bug there.
> >
> > I agree that we should understand how this happened (and asked a similar 
> > question), but I installed a defensive protection anyway.  It cannot do 
> > any harm.
> >
> 
> Okay.  Let's hope this will not hide another real bug.
> 
> I found a way to get such small windows: set window-min-width, 
> window-min-height, window-safe-min-width and window-safe-min-heigth to 0. 
> Of course doing that ignores the fact that the docstring of the 
> window-safe-min-* variables say that "Anything less might crash Emacs", 
> and that their values are 2 (width) and 1 (height).  Which makes me wonder 
> why these variables can be changed / exist.

Maybe Martin (CC'ed) can answer that.

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Eli Zaretskii]

> Date: Wed, 22 Feb 2023 13:40:41 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Eli Zaretskii <eliz@gnu.org>, 61704@debbugs.gnu.org
> 
> 
> >>> How can len possibly be 0 at that point?  It is (in short)
> >
> > Because the pixel width of W is less than its frame's column width. The 
> > division performed window_body_width is truncating, i.e:
> >
> >  24 / 25 = 0
> >
> > and I suspect the actual width being divded at that point is less than 
> > w->pixel_width, since that window had fringes.
> >
> 
> In that case it's a bug in window_body_width I guess, which should do
> 
> /* Don't return a non-positive value.  */
> return max (width / denom, 1);

I won't object to that, if Martin agrees.  But the protection I
installed should IMO remain there, just in case.

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Gregory Heytings <gregory@heytings.org> writes:

> You mean, the ediff popup control frame?

Yes, that's correct.

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Gregory Heytings]

>> You mean, the ediff popup control frame?
>
> Yes, that's correct.
>

Then I'm even more puzzled.  That code is not executed in that frame, it 
is only executed in buffers with long lines.

bug#61704: 29.0.60; Crash in get_narrowed_begv

[martin rudalics]

 >> I found a way to get such small windows: set window-min-width,
 >> window-min-height, window-safe-min-width and window-safe-min-heigth to 0.
 >> Of course doing that ignores the fact that the docstring of the
 >> window-safe-min-* variables say that "Anything less might crash Emacs",
 >> and that their values are 2 (width) and 1 (height).  Which makes me wonder
 >> why these variables can be changed / exist.
 >
 > Maybe Martin (CC'ed) can answer that.

I don't recall the details - if memory doesn't deceive me, the "Anything
less might crash Emacs" phrase was coined by Kim, albeit in a different
context.

These variables exist and can be changed because at the time they were
implemented, there was no real consensus as to which sizes could really
crash Emacs.  The window code itself does not care and the redisplay
code is nowhere explicit about it.

Nowadays these variables are a bad idea because they count (1) lines and
columns and (2) represent total window sizes.  (1) is hampered by the
fact that we now remap faces (do we know whether the return value of
'window-safe-min-pixel-height' is meaningful in such case?) and (2) is
hampered by the presence of window decorations whose sizes are more and
more undetermined so we have to apply brute force measures like

   /* Don't return a negative value.  */
   return max (height / denom, 0);

which appear amateurish (aren't we able to calculate 'height' correctly
in the first place?).

But the real problem here seems that resize_frame_windows has to do what
frame resizing wants and (as _might_ happen with Po's ediff control
frame) there's no guarantee that 'height' is really greater than zero
(or one) there.

So OT1H we really should set proper minimum size hints for the WM to
avoid that resize_frame_windows has to deal with frame sizes it
intrinsically cannot handle and OTOH the redisplay engine should be able
to handle zero window sizes to avoid crashes the window code cannot
prevent.

martin

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

martin rudalics <rudalics@gmx.at> writes:

> So OT1H we really should set proper minimum size hints for the WM to
> avoid that resize_frame_windows has to deal with frame sizes it
> intrinsically cannot handle

Now this is not possible, as the window manager (or any X client, for
that matter) has free reign to do whatever it wants with another
client's window.  Unless of course X server security policy prevents it.

> and OTOH the redisplay engine should be able to handle zero window
> sizes to avoid crashes the window code cannot prevent.

This is the only reasonable approach under X.

bug#61704: 29.0.60; Crash in get_narrowed_begv

[martin rudalics]

 >> So OT1H we really should set proper minimum size hints for the WM to
 >> avoid that resize_frame_windows has to deal with frame sizes it
 >> intrinsically cannot handle
 >
 > Now this is not possible, as the window manager (or any X client, for
 > that matter) has free reign to do whatever it wants with another
 > client's window.  Unless of course X server security policy prevents it.

If a window manager ignores our size hints, a user is free to choose one
which doesn't.  xfwm here respectfully honors the size hints it gets
from Firefox or Thunderbird.  Windows respects minimum size constraints
just as well, BTW.

martin

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Eli Zaretskii]

> Date: Thu, 23 Feb 2023 10:33:42 +0100
> Cc: luangruo@yahoo.com, 61704@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
> So OT1H we really should set proper minimum size hints for the WM to
> avoid that resize_frame_windows has to deal with frame sizes it
> intrinsically cannot handle and OTOH the redisplay engine should be able
> to handle zero window sizes to avoid crashes the window code cannot
> prevent.

As a stopgap, how about adding something to the doc strings regarding
the minimum "safe" values for these "min" variables?  Can you suggest
such values?  They don't have to be the _absolute_ minima, just safe
ones.

Thanks.

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Gregory Heytings <gregory@heytings.org>,
>   61704@debbugs.gnu.org
> Date: Thu, 23 Feb 2023 17:37:48 +0800
> 
> martin rudalics <rudalics@gmx.at> writes:
> 
> > and OTOH the redisplay engine should be able to handle zero window
> > sizes to avoid crashes the window code cannot prevent.
> 
> This is the only reasonable approach under X.

Patches are welcome where this is still not the case.

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Gregory Heytings]

>> and OTOH the redisplay engine should be able to handle zero window 
>> sizes to avoid crashes the window code cannot prevent.
>
> This is the only reasonable approach under X.
>

I maintain that the bug is (was) most probably not in get_narrowed_*.  I 
just built Emacs with the GTK, Lucid and no toolkits, I disabled 
everything (tool-bar, menu-bar, scroll-bar, fringe-mode 0), and even with 
that, after resizing the Emacs frame until it is literally a single pixel 
on screen, I'm not able to get (under emacs -Q) a window width or a height 
equal to 0 there.  The smallest values I get are width = 2 and height = 1.

That, the fact that this code has been there for a half year without a 
single reported crash (if resizing a window is enough to trigger such a 
crash, that would surely have happened already), and the fact that 
get_narrowed_* is not executed at all in the ediff control frame, means 
that there is a bug somewhere else.

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

martin rudalics <rudalics@gmx.at> writes:

>>> So OT1H we really should set proper minimum size hints for the WM to
>>> avoid that resize_frame_windows has to deal with frame sizes it
>>> intrinsically cannot handle
>>
>> Now this is not possible, as the window manager (or any X client, for
>> that matter) has free reign to do whatever it wants with another
>> client's window.  Unless of course X server security policy prevents it.
>
> If a window manager ignores our size hints, a user is free to choose one
> which doesn't.  xfwm here respectfully honors the size hints it gets
> from Firefox or Thunderbird.  Windows respects minimum size constraints
> just as well, BTW.
>
> martin

The problem here is that Emacs should not crash, no matter what some
other X client, such as the WM, does.

X programs are traditionally expected to not crash when run under a
window manager that leaves features unimplemented, but to provide some
kind of graceful fallback instead.

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  Gregory Heytings <gregory@heytings.org>,
>>   61704@debbugs.gnu.org
>> Date: Thu, 23 Feb 2023 17:37:48 +0800
>> 
>> martin rudalics <rudalics@gmx.at> writes:
>> 
>> > and OTOH the redisplay engine should be able to handle zero window
>> > sizes to avoid crashes the window code cannot prevent.
>> 
>> This is the only reasonable approach under X.
>
> Patches are welcome where this is still not the case.

Yes, I'm still alert for more crashes.

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Gregory Heytings <gregory@heytings.org> writes:

> I maintain that the bug is (was) most probably not in get_narrowed_*.
> I just built Emacs with the GTK, Lucid and no toolkits, I disabled
> everything (tool-bar, menu-bar, scroll-bar, fringe-mode 0), and even
> with that, after resizing the Emacs frame until it is literally a
> single pixel on screen, I'm not able to get (under emacs -Q) a window
> width or a height equal to 0 there.  The smallest values I get are
> width = 2 and height = 1.

What if you send a ConfigureNotify event with x, y, width, height all
set to 0, and with a frame font set larger than the font in the ediff
control window?  Or some ridiculous value like (CARD16) -1?

> That, the fact that this code has been there for a half year without a
> single reported crash (if resizing a window is enough to trigger such
> a crash, that would surely have happened already), and the fact that
> get_narrowed_* is not executed at all in the ediff control frame,
> means that there is a bug somewhere else.

Feel free to try to find that other bug, but I can't, since this bug now
seems to be fixed.

Thanks.

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Gregory Heytings]

>
> What if you send a ConfigureNotify event with x, y, width, height all 
> set to 0, and with a frame font set larger than the font in the ediff 
> control window?  Or some ridiculous value like (CARD16) -1?
>

I don't know, I'll try if I have time for that.  But once again: that code 
is not run in the ediff control window.  Not at all.  It is only run when 
displaying buffers in which (long-line-optimizations-p) is non-nil.

>
> Feel free to try to find that other bug, but I can't, since this bug now 
> seems to be fixed.
>

It is not fixed, it is circumvented.

bug#61704: 29.0.60; Crash in get_narrowed_begv

[martin rudalics]

 > As a stopgap, how about adding something to the doc strings regarding
 > the minimum "safe" values for these "min" variables?  Can you suggest
 > such values?  They don't have to be the _absolute_ minima, just safe
 > ones.

There are no such values.  These are Lisp constants and code or user
customizations that set their values or bind them are invalid.
Unfortunately, our tools are not strong enough to prevent that.  And a
doc-string that says

   This variable may be risky if used as a file-local variable.

is misleading at the very least.  Maybe we should emphasize in the
documentations the fact that these are constants.

These constants are here so that after we experience a crash with their
specified values, we can fix the code without having to update all their
occurrences.  And they serve in the documentation to say that the values
of the options 'window-min-width' and 'window-min-height' cannot be
effectively less.

martin

bug#61704: 29.0.60; Crash in get_narrowed_begv

[martin rudalics]

 > I maintain that the bug is (was) most probably not in get_narrowed_*.
 > I just built Emacs with the GTK, Lucid and no toolkits, I disabled
 > everything (tool-bar, menu-bar, scroll-bar, fringe-mode 0), and even
 > with that, after resizing the Emacs frame until it is literally a
 > single pixel on screen, I'm not able to get (under emacs -Q) a window
 > width or a height equal to 0 there.  The smallest values I get are
 > width = 2 and height = 1.

What you listed above is not likely to affect the height of a window -
it's the header, mode and tab lines that count more.

 > That, the fact that this code has been there for a half year without a
 > single reported crash (if resizing a window is enough to trigger such
 > a crash, that would surely have happened already), and the fact that
 > get_narrowed_* is not executed at all in the ediff control frame,
 > means that there is a bug somewhere else.

Don't worry.  What Po Lu saw is something I've seen in different forms
much earlier.  Small frames can be a problem for redisplay.

martin

bug#61704: 29.0.60; Crash in get_narrowed_begv

[martin rudalics]

Which BTW is not entirely trivial to do.
 > The problem here is that Emacs should not crash, no matter what some
 > other X client, such as the WM, does.

Right.  Even if we have no proof that frame resizing is the culprit
here.

 > X programs are traditionally expected to not crash when run under a
 > window manager that leaves features unimplemented, but to provide some
 > kind of graceful fallback instead.

Right again.  And that's why I said that

 > and OTOH the redisplay engine should be able to handle zero window
 > sizes to avoid crashes the window code cannot prevent.

martin

bug#61704: 29.0.60; Crash in get_narrowed_begv

[Gregory Heytings]

>> I maintain that the bug is (was) most probably not in get_narrowed_*. I 
>> just built Emacs with the GTK, Lucid and no toolkits, I disabled 
>> everything (tool-bar, menu-bar, scroll-bar, fringe-mode 0), and even 
>> with that, after resizing the Emacs frame until it is literally a 
>> single pixel on screen, I'm not able to get (under emacs -Q) a window 
>> width or a height equal to 0 there.  The smallest values I get are 
>> width = 2 and height = 1.
>
> What you listed above is not likely to affect the height of a window - 
> it's the header, mode and tab lines that count more.
>

Yes, I disabled all this to make sure the frame (and therefore the windows 
on the frame) would become as small as possible.  I tested this with emacs 
-Q, with several windows on the frame displaying a buffer in which 
(long-line-optimizations-p) is non-nil, without any header line or tab 
line.

Perhaps I should have tried to disable the mode-line.  Let's see...

M-: (setq mode-line-format nil) RET

No, still no way to get a zero height or width.  Increasing or decreasing 
the font size in the buffer also has no effect, I can't get a zero height 
or width.

>
> Don't worry.  What Po Lu saw is something I've seen in different forms 
> much earlier.  Small frames can be a problem for redisplay.
>

Indeed.

bug#61704: 29.0.60; Crash in get_narrowed_begv

[martin rudalics]

 > Yes, I disabled all this to make sure the frame (and therefore the windows on the frame) would become as small as possible.  I tested this with emacs -Q, with several windows on the frame displaying a buffer in which (long-line-optimizations-p) is non-nil, without any header line or tab line.
 >
 > Perhaps I should have tried to disable the mode-line.  Let's see...
 >
 > M-: (setq mode-line-format nil) RET
 >
 > No, still no way to get a zero height or width.  Increasing or decreasing the font size in the buffer also has no effect, I can't get a zero height or width.

Disabling mode lines means you're working in the wrong direction.  Frame
resizing always tries to make windows at least one line high and two
columns wide.  You have to make a small window and make its mode lines
tall.  Then you have a chance to crash redisplay with macros like
WINDOW_BOX_HEIGHT_NO_MODE_LINE and WINDOW_BOX_TEXT_HEIGHT that subtract
mode line heights from a window's total height.

martin