bug#56561: 29.0.50; Infloop in try_window

bug#56561: 29.0.50; Infloop in try_window

[Michael Welsh Duggan]

No recipe for this.  In the course of using Emacs, I ended up in an
infloop in `try_window`.

I've connected to this in gdb.  `try_window' is calling `display_line'
in a loop until the iterator hits a certain point.  But `display_line',
in this case, isn't modifying the iterator, so the loop never ends.
Here follows part of the debugging session demonstrating this.  I'll
keep this gdb session alive for a while.

try_window (window=window@entry=XIL(0x55555b4301f5), pos=..., flags=flags@entry=2) at ../../md5i/src/xdisp.c:20208
20208         if (f->fonts_changed && !(flags & TRY_WINDOW_IGNORE_FONTS_CHANGE))
(gdb) n
20204     while (it.current_y < it.last_visible_y)
(gdb) p it.current_y
$11 = 595
(gdb) p it.last_visible_y
$12 = 680
(gdb) n
20206         if (display_line (&it, cursor_vpos))
(gdb) s
display_line (it=it@entry=0x7fffffffb770, cursor_vpos=cursor_vpos@entry=0) at ../../md5i/src/xdisp.c:24140
24140   {
(gdb) n
24141     struct glyph_row *row = it->glyph_row;
(gdb) 
24154     ptrdiff_t min_pos = ZV + 1, max_pos = 0;
(gdb) 
24157     int tab_line = window_wants_tab_line (it->w);
(gdb) 
24158     int header_line = window_wants_header_line (it->w);
(gdb) 
24159     bool hscroll_this_line = (cursor_vpos >= 0
(gdb) 
24162     int first_visible_x = it->first_visible_x;
(gdb) 
24163     int last_visible_x = it->last_visible_x;
(gdb) 
24169     if (MATRIX_ROW_VPOS (row, it->w->desired_matrix)
(gdb) 
24172         it->w->nrows_scale_factor++;
(gdb) p it->w->nrows_scale_factor
$13 = 2064109537
(gdb) n
24173         it->f->fonts_changed = true;
(gdb) 
24174         return false;
(gdb) 
try_window (window=window@entry=XIL(0x55555b4301f5), pos=..., flags=flags@entry=2) at ../../md5i/src/xdisp.c:20208
20208         if (f->fonts_changed && !(flags & TRY_WINDOW_IGNORE_FONTS_CHANGE))
(gdb) 
20204     while (it.current_y < it.last_visible_y)




In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0)
 of 2022-07-03 built on miko
Repository revision: e41ba8ab89a125c91dee672845679f2dec19853a
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux bookworm/sid

Configured using:
 'configure --without-toolkit-scroll-bars --with-x-toolkit=lucid
 --with-native-compilation --with-xinput2 'CFLAGS=-Og -ggdb''

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF X11
XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  flyspell-mode: t
  display-time-mode: t
  magit-wip-initial-backup-mode: t
  magit-wip-before-change-mode: t
  magit-wip-after-apply-mode: t
  magit-wip-after-save-mode: t
  magit-wip-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  line-number-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/md5i/.config/emacs/elpa/transient-20220514.945/transient hides /home/md5i/src/emacs/md5i/lisp/transient

Features:
(shadow sort mail-extr gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime
smime gnutls dig gnus-sum shr pixel-fill kinsoku url-file url-dired svg
gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud gnus-spec gnus-win
emacsbug goto-addr bug-reference thingatpt mule-util face-remap
dired-aux flyspell ispell view pacproxy descr-text tramp tramp-loaddefs
trampver tramp-integration cus-edit pp cus-load files-x tramp-compat
parse-time iso8601 ls-lisp time sieve-manage sasl sasl-anonymous
sasl-login sasl-plain rng-loc rng-uri rng-parse rng-match rng-dt
rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util
sgml-mode facemenu dom python ps-print ps-print-loaddefs ps-def lpr
picture nm dbus xml magit-submodule magit-obsolete magit-blame
magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch
magit-clone magit-remote magit-commit magit-sequence magit-notes
magit-worktree magit-tag magit-merge magit-branch magit-reset
magit-files magit-refs magit-status magit magit-repos magit-apply
magit-wip magit-log which-func imenu magit-diff smerge-mode diff
diff-mode easy-mmode git-commit log-edit pcvs-util add-log magit-core
magit-autorevert autorevert filenotify magit-margin magit-transient
magit-process with-editor shell pcomplete server magit-mode transient
comp comp-cstr warnings rx cl-extra edmacro kmacro help-mode magit-git
magit-base magit-section format-spec crm dash compat-27 compat-26 compat
nnimap nnmail gnus-int mail-source gnus-range message sendmail
yank-media rfc822 mml mml-sec epa mm-decode mm-bodies mm-encode
mailabbrev gmm-utils mailheader utf7 netrc nnoo gnus wid-edit nnheader
gnus-util time-date mail-utils range gnus-o365-oauth2 oauth2 url-http
url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr url-gw nsm puny plstore generated generic-x epg rfc6068
epg-config ediff ediff-merg ediff-mult ediff-wind ediff-diff ediff-help
ediff-init ediff-util dired-x dired dired-loaddefs compile
text-property-search comint ring ansi-color cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs derived
debian-el rainbow-delimiters-autoloads info package browse-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map byte-opt gv bytecomp byte-compile cconv
url-vars cl-loaddefs cl-lib rmc iso-transl tooltip eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
faces cus-face macroexp files window text-properties overlay sha1 md5
base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 380223 18419)
 (symbols 48 27063 2)
 (strings 32 95513 5733)
 (string-bytes 1 3154480)
 (vectors 16 56391)
 (vector-slots 8 955380 21517)
 (floats 8 665 186)
 (intervals 56 3263 950)
 (buffers 992 18))

-- 
Michael Welsh Duggan
(md5i@md5i.com)

bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> From: Michael Welsh Duggan <md5i@md5i.com>
> Date: Thu, 14 Jul 2022 14:57:40 -0400
> 
> I've connected to this in gdb.  `try_window' is calling `display_line'
> in a loop until the iterator hits a certain point.  But `display_line',
> in this case, isn't modifying the iterator, so the loop never ends.
> Here follows part of the debugging session demonstrating this.  I'll
> keep this gdb session alive for a while.

I need to see what's in the buffer and some other variables.  These
are for the call-stack frame inside display_line:

  (gdb) p current_buffer->text->beg
  (gdb) p it->current
  (gdb) p it->w->desired_matrix->nrows
  (gdb) p MATRIX_ROW_VPOS(row, it->w->desired_matrix)
  (gdb) thread apply all bt
  (gdb) xbacktrace

And finally, any idea what you were doing when this happened?

Thanks.

bug#56561: 29.0.50; Infloop in try_window

[Michael Welsh Duggan]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Welsh Duggan <md5i@md5i.com>
>> Date: Thu, 14 Jul 2022 14:57:40 -0400
>> 
>> I've connected to this in gdb.  `try_window' is calling `display_line'
>> in a loop until the iterator hits a certain point.  But `display_line',
>> in this case, isn't modifying the iterator, so the loop never ends.
>> Here follows part of the debugging session demonstrating this.  I'll
>> keep this gdb session alive for a while.
>
> I need to see what's in the buffer and some other variables.  These
> are for the call-stack frame inside display_line:
>
>   (gdb) p current_buffer->text->beg
>   (gdb) p it->current
>   (gdb) p it->w->desired_matrix->nrows
>   (gdb) p MATRIX_ROW_VPOS(row, it->w->desired_matrix)
>   (gdb) thread apply all bt
>   (gdb) xbacktrace
>
> And finally, any idea what you were doing when this happened?

Moving my cursor between frames and either clicking or typing C-p, I
think.  The emacs was on a remote machine at the time, visible via X11
over ssh.  This may have slowed X events enough for some corner
condition to be achieved.

(gdb) p current_thread->m_current_buffer->text->beg
$15 = (unsigned char *) 0x555557bb75a0 "mouse-2: correct word at point"
(gdb) p it->current
$16 = {
  pos = {
    charpos = 31,
    bytepos = 31
  },
  overlay_string_index = -1,
  string_pos = {
    charpos = -1,
    bytepos = -1
  },
  dpvec_index = -1
}
(gdb) p it->w->desired_matrix->nrows
$17 = 35
(gdb) p MATRIX_ROW_VPOS(row, it->w->desired_matrix)
No symbol "MATRIX_ROW_VPOS" in current context.
(gdb) p row - it->w->desired_matrix->rows
$18 = 35


Thread 4 (Thread 0x7fffe7fff640 (LWP 1400080) "gdbus"):
#0  0x00007ffff3cb487f in __GI___poll (fds=0x7ffff6b0f4e0, nfds=140737331255742, timeout=32767) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007fffe0016990 in  ()
#2  0x00007fffe0016990 in  ()
#3  0x0000000000000002 in  ()
#4  0xffffffff00000001 in  ()
#5  0x00007fffe0014ca0 in  ()
#6  0x00007ffff6a2e1ee in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0x00007ffff6a2e543 in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x00007ffff6cc3cf6 in  () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#9  0x00007fffe0002de0 in  ()
#10 0x00007ffff6a5859d in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007ffff61a6d80 in start_thread (arg=0x7fffe7fff640) at pthread_create.c:481
#12 0x00007ffff3cc076f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
#13 0x0000000000000000 in  ()

Lisp Backtrace:
"x-show-tip" (0xffffcdb0)
"tooltip-show" (0xffffced8)
"tooltip-help-tips" (0xffffd038)
"tooltip-timeout" (0xffffd278)
"apply" (0xffffd270)
"timer-event-handler" (0xffffd3f8)

Thread 3 (Thread 0x7fffece4a640 (LWP 1400079) "dconf worker"):
#0  0x00007ffff3cb487f in __GI___poll (fds=0x7ffff6b0f4e0, nfds=140737331255742, timeout=32767) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00005555573d6900 in  ()
#2  0x00005555573d6900 in  ()
#3  0x0000000000000001 in  ()
#4  0xffffffff00000001 in  ()
#5  0x00005555573d6810 in  ()
#6  0x00007ffff6a2e1ee in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0x00007ffff6a2e30f in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x00007fffeceab3bd in  () at /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
#9  0x00007ffff6a5859d in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007ffff61a6d80 in start_thread (arg=0x7fffece4a640) at pthread_create.c:481
#11 0x00007ffff3cc076f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
#12 0x0000000000000000 in  ()

Lisp Backtrace:
"x-show-tip" (0xffffcdb0)
"tooltip-show" (0xffffced8)
"tooltip-help-tips" (0xffffd038)
"tooltip-timeout" (0xffffd278)
"apply" (0xffffd270)
"timer-event-handler" (0xffffd3f8)

Thread 2 (Thread 0x7fffee6ca640 (LWP 1399543) "gmain"):
#0  0x00007ffff3cb487f in __GI___poll (fds=0x7ffff6b0f4e0, nfds=140737331255742, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x0000555555ccf0d0 in  ()
#2  0x0000555555ccf0d0 in  ()
#3  0x0000000000000001 in  ()
#4  0xffffffff00000001 in  ()
#5  0x0000555555edd870 in  ()
#6  0x00007ffff6a2e1ee in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0x00007ffff6a2e30f in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x00007ffff6a2e361 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x00007ffff6a5859d in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007ffff61a6d80 in start_thread (arg=0x7fffee6ca640) at pthread_create.c:481
#11 0x00007ffff3cc076f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
#12 0x0000000000000000 in  ()

Lisp Backtrace:
"x-show-tip" (0xffffcdb0)
"tooltip-show" (0xffffced8)
"tooltip-help-tips" (0xffffd038)
"tooltip-timeout" (0xffffd278)
"apply" (0xffffd270)
"timer-event-handler" (0xffffd3f8)

Thread 1 (Thread 0x7ffff05e1380 (LWP 1399519) "emacs"):
#0  0x00005555555e461a in display_line (it=it@entry=0x7fffffffb770, cursor_vpos=cursor_vpos@entry=0) at ../../md5i/src/xdisp.c:24169
#1  0x00005555555e7e01 in try_window (window=window@entry=XIL(0x55555b4301f5), pos=..., flags=flags@entry=2) at ../../md5i/src/xdisp.c:20206
#2  0x00005555556ad347 in Fx_show_tip (string=<optimized out>, frame=<optimized out>, parms=XIL(0x55556045d6d3), timeout=<optimized out>, dx=<optimized out>, dy=<optimized out>) at ../../md5i/src/xfns.c:8752
#3  0x0000555555754d86 in funcall_subr (subr=0x555555bd1c20 <Sx_show_tip>, numargs=numargs@entry=6, args=args@entry=0x7fffffffcdb0) at ../../md5i/src/eval.c:3006
#4  0x0000555555752ca4 in funcall_general (fun=<optimized out>, numargs=numargs@entry=6, args=args@entry=0x7fffffffcdb0) at ../../md5i/src/eval.c:2904
#5  0x0000555555753131 in Ffuncall (nargs=7, args=0x7fffffffcda8) at ../../md5i/src/eval.c:2958
#6  0x00007fffeee6ed9d in F746f6f6c7469702d73686f77_tooltip_show_0 () at /home/md5i/src/emacs/build/src/../native-lisp/29.0.50-bb581598/preloaded/tooltip-29462ede-0f14bf43.eln
#7  0x0000555555754d4f in funcall_subr (subr=0x7fffef911310, numargs=numargs@entry=2, args=args@entry=0x7fffffffced8) at ../../md5i/src/eval.c:3002
#8  0x0000555555752ca4 in funcall_general (fun=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffffffced8) at ../../md5i/src/eval.c:2904
#9  0x0000555555753131 in Ffuncall (nargs=3, args=0x7fffffffced0) at ../../md5i/src/eval.c:2958
#10 0x00007fffeee6f968 in F746f6f6c7469702d68656c702d74697073_tooltip_help_tips_0 () at /home/md5i/src/emacs/build/src/../native-lisp/29.0.50-bb581598/preloaded/tooltip-29462ede-0f14bf43.eln
#11 0x0000555555754d16 in funcall_subr (subr=0x7fffef912e38, numargs=numargs@entry=1, args=args@entry=0x7fffffffd038) at ../../md5i/src/eval.c:2996
#12 0x0000555555752ca4 in funcall_general (fun=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffffd038) at ../../md5i/src/eval.c:2904
#13 0x0000555555753131 in Ffuncall (nargs=2, args=0x7fffffffd030) at ../../md5i/src/eval.c:2958
#14 0x0000555555751f6c in run_hook_with_args (nargs=2, args=0x7fffffffd030, funcall=funcall@entry=0x555555753016 <Ffuncall>) at ../../md5i/src/eval.c:2817
#15 0x00005555557521df in Frun_hook_with_args_until_success (nargs=<optimized out>, args=<optimized out>) at ../../md5i/src/eval.c:2703
#16 0x00007fffeee6e964 in F746f6f6c7469702d74696d656f7574_tooltip_timeout_0 () at /home/md5i/src/emacs/build/src/../native-lisp/29.0.50-bb581598/preloaded/tooltip-29462ede-0f14bf43.eln
#17 0x0000555555754d16 in funcall_subr (subr=0x7fffef911db8, numargs=numargs@entry=1, args=args@entry=0x7fffffffd278) at ../../md5i/src/eval.c:2996
#18 0x0000555555752ca4 in funcall_general (fun=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffffd278) at ../../md5i/src/eval.c:2904
#19 0x0000555555753131 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffd270) at ../../md5i/src/eval.c:2958
#20 0x0000555555753c70 in Fapply (nargs=2, args=0x7fffffffd270) at ../../md5i/src/eval.c:2586
#21 0x0000555555754de9 in funcall_subr (subr=0x555555bdf060 <Sapply>, numargs=numargs@entry=2, args=args@entry=0x7fffffffd270) at ../../md5i/src/eval.c:3023
#22 0x0000555555752ca4 in funcall_general (fun=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffffffd270) at ../../md5i/src/eval.c:2904
#23 0x0000555555753131 in Ffuncall (nargs=3, args=0x7fffffffd268) at ../../md5i/src/eval.c:2958
#24 0x00007fffef039e90 in F74696d65722d6576656e742d68616e646c6572_timer_event_handler_0 () at /home/md5i/src/emacs/build/src/../native-lisp/29.0.50-bb581598/preloaded/timer-3ee7cfd9-76499eee.eln
#25 0x0000555555754d16 in funcall_subr (subr=0x7ffff0025ad0, numargs=numargs@entry=1, args=args@entry=0x7fffffffd3f8) at ../../md5i/src/eval.c:2996
#26 0x0000555555752ca4 in funcall_general (fun=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffffd3f8) at ../../md5i/src/eval.c:2904
#27 0x0000555555753131 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffd3f0) at ../../md5i/src/eval.c:2958
#28 0x00005555556c3cf3 in call1 (arg1=XIL(0x55555bd20ee5), fn=XIL(0xf390)) at ../../md5i/src/lisp.h:3239
#29 timer_check_2 (timers=<optimized out>, timers@entry=XIL(0x55555c403a33), idle_timers=<optimized out>, idle_timers@entry=XIL(0x55555c403803)) at ../../md5i/src/keyboard.c:4599
#30 0x00005555556d1ec0 in timer_check () at ../../md5i/src/keyboard.c:4665
#31 0x00005555556d1f10 in readable_events (flags=1) at ../../md5i/src/keyboard.c:3492
#32 0x00005555556d2254 in get_input_pending (flags=flags@entry=1) at ../../md5i/src/keyboard.c:7240
#33 0x00005555556d238f in swallow_events (do_display=do_display@entry=false) at ../../md5i/src/keyboard.c:4406
#34 0x00005555556d4a90 in read_char (commandflag=1, map=map@entry=XIL(0x55555eba43d3), prev_event=XIL(0), used_mouse_menu=used_mouse_menu@entry=0x7fffffffd7eb, end_time=end_time@entry=0x0) at ../../md5i/src/keyboard.c:2585
#35 0x00005555556d67eb in read_key_sequence (keybuf=keybuf@entry=0x7fffffffd8c0, prompt=prompt@entry=XIL(0), dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false) at ../../md5i/src/keyboard.c:9947
#36 0x00005555556d8257 in command_loop_1 () at ../../md5i/src/keyboard.c:1391
#37 0x00005555557518a6 in internal_condition_case (bfun=bfun@entry=0x5555556d805e <command_loop_1>, handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x5555556c8fb3 <cmd_error>) at ../../md5i/src/eval.c:1485
#38 0x00005555556c22a1 in command_loop_2 (handlers=handlers@entry=XIL(0x90)) at ../../md5i/src/keyboard.c:1132
#39 0x000055555575181d in internal_catch (tag=tag@entry=XIL(0xf690), func=func@entry=0x5555556c2287 <command_loop_2>, arg=arg@entry=XIL(0x90)) at ../../md5i/src/eval.c:1208
#40 0x00005555556c2264 in command_loop () at ../../md5i/src/keyboard.c:1110
#41 0x00005555556c8b5a in recursive_edit_1 () at ../../md5i/src/keyboard.c:719
#42 0x00005555556c8eef in Frecursive_edit () at ../../md5i/src/keyboard.c:802
#43 0x00005555556c194f in main (argc=2, argv=0x7fffffffdc68) at ../../md5i/src/emacs.c:2517

Lisp Backtrace:
"x-show-tip" (0xffffcdb0)
"tooltip-show" (0xffffced8)
"tooltip-help-tips" (0xffffd038)
"tooltip-timeout" (0xffffd278)
"apply" (0xffffd270)
"timer-event-handler" (0xffffd3f8)


-- 
Michael Welsh Duggan
(md5i@md5i.com)

bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> From: Michael Welsh Duggan <mwd@md5i.com>
> Cc: 56561@debbugs.gnu.org
> Date: Thu, 14 Jul 2022 18:44:43 -0400
> 
> Moving my cursor between frames and either clicking or typing C-p, I
> think.  The emacs was on a remote machine at the time, visible via X11
> over ssh.  This may have slowed X events enough for some corner
> condition to be achieved.

All I see is that Emacs tried to display a tooltip.

> (gdb) p current_thread->m_current_buffer->text->beg
> $15 = (unsigned char *) 0x555557bb75a0 "mouse-2: correct word at point"
> (gdb) p it->current
> $16 = {
>   pos = {
>     charpos = 31,
>     bytepos = 31
>   },
>   overlay_string_index = -1,
>   string_pos = {
>     charpos = -1,
>     bytepos = -1
>   },
>   dpvec_index = -1
> }
> (gdb) p it->w->desired_matrix->nrows
> $17 = 35
> 
> (gdb) p MATRIX_ROW_VPOS(row, it->w->desired_matrix)
> No symbol "MATRIX_ROW_VPOS" in current context.
> (gdb) p row - it->w->desired_matrix->rows
> $18 = 35

Hmm... so the short tooltip text somehow causes us to exceed the
number of glyph rows of the matrix?  Please tell what the commands
below show:

 (gdb) pgrowx it->w->desired_matrix->rows
 (gdb) pgrowx it->w->desired_matrix->rows+1
 (gdb) pgrowx it->w->desired_matrix->rows+2
 (gdb) pgrowx it->w->desired_matrix->rows+3
 ...
 (gdb) pgrowx it->w->desired_matrix->rows+34

That is, I want to see the entire contents of the glyph rows.

Also

 (gdb) p it->last_visible_x
 (gdb) p it->last_visible_y

Thanks.

bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> Cc: 56561@debbugs.gnu.org
> Date: Fri, 15 Jul 2022 09:14:10 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> Hmm... so the short tooltip text somehow causes us to exceed the
> number of glyph rows of the matrix?  Please tell what the commands
> below show:
> 
>  (gdb) pgrowx it->w->desired_matrix->rows
>  (gdb) pgrowx it->w->desired_matrix->rows+1
>  (gdb) pgrowx it->w->desired_matrix->rows+2
>  (gdb) pgrowx it->w->desired_matrix->rows+3
>  ...
>  (gdb) pgrowx it->w->desired_matrix->rows+34
> 
> That is, I want to see the entire contents of the glyph rows.
> 
> Also
> 
>  (gdb) p it->last_visible_x
>  (gdb) p it->last_visible_y

Actually, I think I see the reason.  I installed a fix, but I cannot
find a way of triggering the problem, so I cannot be 110% sure this is
fixed.  I guess time will tell.

Thanks.

bug#56561: 29.0.50; Infloop in try_window

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

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 56561@debbugs.gnu.org
>> Date: Fri, 15 Jul 2022 09:14:10 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> 
>> Hmm... so the short tooltip text somehow causes us to exceed the
>> number of glyph rows of the matrix?  Please tell what the commands
>> below show:
>> 
>>  (gdb) pgrowx it->w->desired_matrix->rows
>>  (gdb) pgrowx it->w->desired_matrix->rows+1
>>  (gdb) pgrowx it->w->desired_matrix->rows+2
>>  (gdb) pgrowx it->w->desired_matrix->rows+3
>>  ...
>>  (gdb) pgrowx it->w->desired_matrix->rows+34
>> 
>> That is, I want to see the entire contents of the glyph rows.
>> 
>> Also
>> 
>>  (gdb) p it->last_visible_x
>>  (gdb) p it->last_visible_y
>
> Actually, I think I see the reason.  I installed a fix, but I cannot
> find a way of triggering the problem, so I cannot be 110% sure this is
> fixed.  I guess time will tell.

BTW, I have a question about the fix: redisplay cannot run when a
tooltip is displayed as popup menu help-text, so adjust_glyph_matrix and
the subsequent try_window call that is required to generate the display
contents will not be called in time, leading to a blank tooltip.

The call could previously never fail, since the tooltip code specifies
TRY_WINDOW_IGNORE_FONTS_CHANGE.

Would it be appropriate to call adjust_frame_glyphs and try_window again
if this call to try_window in Fx_show_tip fails?

  specpdl_ref count_1 = SPECPDL_INDEX ();
  old_buffer = current_buffer;
  set_buffer_internal_1 (XBUFFER (w->contents));
  bset_truncate_lines (current_buffer, Qnil);
  specbind (Qinhibit_read_only, Qt);
  specbind (Qinhibit_modification_hooks, Qt);
  specbind (Qinhibit_point_motion_hooks, Qt);
  Ferase_buffer ();
  Finsert (1, &string);
  clear_glyph_matrix (w->desired_matrix);
  clear_glyph_matrix (w->current_matrix);
  SET_TEXT_POS (pos, BEGV, BEGV_BYTE);
->try_window (window, pos, TRY_WINDOW_IGNORE_FONTS_CHANGE);
  /* Calculate size of tooltip window.  */
  size = Fwindow_text_pixel_size (window, Qnil, Qnil, Qnil,
				  make_fixnum (w->pixel_height), Qnil,
				  Qnil);

Thanks.

bug#56561: 29.0.50; Infloop in try_window

[Michael Welsh Duggan]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 56561@debbugs.gnu.org
>> Date: Fri, 15 Jul 2022 09:14:10 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> 
>> Hmm... so the short tooltip text somehow causes us to exceed the
>> number of glyph rows of the matrix?  Please tell what the commands
>> below show:
>> 
>>  (gdb) pgrowx it->w->desired_matrix->rows
>>  (gdb) pgrowx it->w->desired_matrix->rows+1
>>  (gdb) pgrowx it->w->desired_matrix->rows+2
>>  (gdb) pgrowx it->w->desired_matrix->rows+3
>>  ...
>>  (gdb) pgrowx it->w->desired_matrix->rows+34
>> 
>> That is, I want to see the entire contents of the glyph rows.
>> 
>> Also
>> 
>>  (gdb) p it->last_visible_x
>>  (gdb) p it->last_visible_y
>
> Actually, I think I see the reason.  I installed a fix, but I cannot
> find a way of triggering the problem, so I cannot be 110% sure this is
> fixed.  I guess time will tell.

Sounds good.  I, unfortunately, lost my debug session due to an
unrelated window manager problem.  I'll certainly let you know if I ever
run into this again.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: mwd@md5i.com,  56561@debbugs.gnu.org
> Date: Fri, 15 Jul 2022 21:54:24 +0800
> 
> BTW, I have a question about the fix: redisplay cannot run when a
> tooltip is displayed as popup menu help-text, so adjust_glyph_matrix and
> the subsequent try_window call that is required to generate the display
> contents will not be called in time, leading to a blank tooltip.
> 
> The call could previously never fail, since the tooltip code specifies
> TRY_WINDOW_IGNORE_FONTS_CHANGE.
> 
> Would it be appropriate to call adjust_frame_glyphs and try_window again
> if this call to try_window in Fx_show_tip fails?

You mean, adjust_frame_glyphs, right?

We probably should do that, but my problem is that I cannot reproduce
the original issue: whatever I try, the condition

    it.current_y < it.last_visible_y

happens before

    MATRIX_ROW_VPOS (row, it->w->desired_matrix)
      >= it->w->desired_matrix->nrows

We need a recipe to trigger the reverse, to be able to test a
solution.

bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> Cc: mwd@md5i.com, 56561@debbugs.gnu.org
> Date: Fri, 15 Jul 2022 17:24:26 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Po Lu <luangruo@yahoo.com>
> > Cc: mwd@md5i.com,  56561@debbugs.gnu.org
> > Date: Fri, 15 Jul 2022 21:54:24 +0800
> > 
> > BTW, I have a question about the fix: redisplay cannot run when a
> > tooltip is displayed as popup menu help-text, so adjust_glyph_matrix and
> > the subsequent try_window call that is required to generate the display
> > contents will not be called in time, leading to a blank tooltip.
> > 
> > The call could previously never fail, since the tooltip code specifies
> > TRY_WINDOW_IGNORE_FONTS_CHANGE.
> > 
> > Would it be appropriate to call adjust_frame_glyphs and try_window again
> > if this call to try_window in Fx_show_tip fails?
> 
> You mean, adjust_frame_glyphs, right?
> 
> We probably should do that

On second thought, I take this back.  I don't see how we could have a
blank tooltip.  We call try_window just so we could compute the size
of the text in it, which then allows us to know the size of the
tooltip.  The situation where nrows_scale_factor is increased happens
when we get to the bottom of the window, which for a tooltip means we
already laid out all the text and are just producing empty glyph rows
beyond the end of the text.  ncols_scale_factor could theoretically
happen before we reach the end of the text, but I'd like to see
something like that happening before I believe it; and even if it does
happen in the very first line, the tooltip will not be empty, just
truncated.

So I cannot see how this case could produce an empty tooltip, and I
have hard time imagining how it could even produce a truncated text.
We could add an assertion to verify that try_window gets to ZV in this
case before it returns, if we want to be able to detect those cases.

> We need a recipe to trigger the reverse, to be able to test a
> solution.

That part is still true.

bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> Cc: mwd@md5i.com, 56561@debbugs.gnu.org
> Date: Fri, 15 Jul 2022 18:27:15 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Cc: mwd@md5i.com, 56561@debbugs.gnu.org
> > Date: Fri, 15 Jul 2022 17:24:26 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > > From: Po Lu <luangruo@yahoo.com>
> > > Cc: mwd@md5i.com,  56561@debbugs.gnu.org
> > > Date: Fri, 15 Jul 2022 21:54:24 +0800
> > > 
> > > BTW, I have a question about the fix: redisplay cannot run when a
> > > tooltip is displayed as popup menu help-text, so adjust_glyph_matrix and
> > > the subsequent try_window call that is required to generate the display
> > > contents will not be called in time, leading to a blank tooltip.
> > > 
> > > The call could previously never fail, since the tooltip code specifies
> > > TRY_WINDOW_IGNORE_FONTS_CHANGE.
> > > 
> > > Would it be appropriate to call adjust_frame_glyphs and try_window again
> > > if this call to try_window in Fx_show_tip fails?
> > 
> > You mean, adjust_frame_glyphs, right?
> > 
> > We probably should do that
> 
> On second thought, I take this back.  I don't see how we could have a
> blank tooltip.  We call try_window just so we could compute the size
> of the text in it, which then allows us to know the size of the
> tooltip.

On third thought, why do we even call try_window there?  The original
code needed try_window because it then used the glyph matrix it
produces to calculate the size of the tooltip.  But we've dumped that
code, and we nowadays use window-text-pixel-size instead, which
emulates the display internally anyway.  So I think we should simply
delete the call to try_window from x-show-tip, and be done.  At least
on master.

bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> Cc: mwd@md5i.com, 56561@debbugs.gnu.org
> Date: Fri, 15 Jul 2022 18:37:50 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> On third thought, why do we even call try_window there?  The original
> code needed try_window because it then used the glyph matrix it
> produces to calculate the size of the tooltip.  But we've dumped that
> code, and we nowadays use window-text-pixel-size instead, which
> emulates the display internally anyway.  So I think we should simply
> delete the call to try_window from x-show-tip, and be done.  At least
> on master.

No, that's wrong: we call update_single_window there, and that
requires a window with a desired matrix set up correctly.  So yes, the
call to try_window is still needed.

bug#56561: 29.0.50; Infloop in try_window

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

Eli Zaretskii <eliz@gnu.org> writes:

> You mean, adjust_frame_glyphs, right?

I thought that was what I said.

> We probably should do that, but my problem is that I cannot reproduce
> the original issue: whatever I try, the condition
>
>     it.current_y < it.last_visible_y
>
> happens before
>
>     MATRIX_ROW_VPOS (row, it->w->desired_matrix)
>       >= it->w->desired_matrix->nrows
>
> We need a recipe to trigger the reverse, to be able to test a
> solution.

I can't find one either, yes.  Maybe it has something to do with some
installed fonts?

bug#56561: 29.0.50; Infloop in try_window

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

Eli Zaretskii <eliz@gnu.org> writes:

> On second thought, I take this back.  I don't see how we could have a
> blank tooltip.  We call try_window just so we could compute the size
> of the text in it, which then allows us to know the size of the
> tooltip.  The situation where nrows_scale_factor is increased happens
> when we get to the bottom of the window, which for a tooltip means we
> already laid out all the text and are just producing empty glyph rows
> beyond the end of the text.  ncols_scale_factor could theoretically
> happen before we reach the end of the text, but I'd like to see
> something like that happening before I believe it; and even if it does
> happen in the very first line, the tooltip will not be empty, just
> truncated.

No, we call try_window to generate the window contents, and then call
update_single_window followed by flush_frame to immediately flush the
contents to display.

This is because redisplay actually cannot run by itself in some cases
where we do want tooltips to be displayed.

> We could add an assertion to verify that try_window gets to ZV in this
> case before it returns, if we want to be able to detect those cases.

This could still work.  I think `TRY_WINDOW_IGNORE_FONTS_CHANGE' means
the caller isn't ready for try_window to fail.

bug#56561: 29.0.50; Infloop in try_window

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

Eli Zaretskii <eliz@gnu.org> writes:

> On third thought, why do we even call try_window there?  The original
> code needed try_window because it then used the glyph matrix it
> produces to calculate the size of the tooltip.  But we've dumped that
> code, and we nowadays use window-text-pixel-size instead, which
> emulates the display internally anyway.  So I think we should simply
> delete the call to try_window from x-show-tip, and be done.  At least
> on master.

That leads to blank tooltips inside popup menus.

Here is the vital code in this case:

  clear_glyph_matrix (w->desired_matrix);
  clear_glyph_matrix (w->current_matrix);
  SET_TEXT_POS (pos, BEGV, BEGV_BYTE);
  try_window (window, pos, TRY_WINDOW_IGNORE_FONTS_CHANGE);
  [...]
  w->must_be_updated_p = true;
  update_single_window (w);
  flush_frame (tip_f);

Otherwise, the contents of the tooltip will not be visible by the time
the tooltip is displayed, and will not be generated, as redisplay cannot
happen inside a popup menu.

bug#56561: 29.0.50; Infloop in try_window

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

Eli Zaretskii <eliz@gnu.org> writes:

> No, that's wrong: we call update_single_window there, and that
> requires a window with a desired matrix set up correctly.  So yes, the
> call to try_window is still needed.

Indeed.  So would you prefer an assertion in try_window, or a call to
adjust_frame_glyphs if it fails?

Thanks.

bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: mwd@md5i.com,  56561@debbugs.gnu.org
> Date: Sat, 16 Jul 2022 11:15:55 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > No, that's wrong: we call update_single_window there, and that
> > requires a window with a desired matrix set up correctly.  So yes, the
> > call to try_window is still needed.
> 
> Indeed.  So would you prefer an assertion in try_window

Not sure which assertion you had in mind.  It cannot be easily done
inside try_window, because that function is called from many places
unrelated to tooltips.

What I had in mind is an assertion in x-show-tip that the glyph matrix
produced by try_window includes all of the tooltip text, i.e. that
there's a glyph row there whose ends_at_zv_p flag is set.  This is an
indication that all of the text was processed and will appear in the
tooltip.

Note that in the case in point this is precisely what's happened: the
entire text of the tip was processed and produced its glyphs, and the
problem happened while try_window was producing empty glyph rows
beyond ZV.

> or a call to adjust_frame_glyphs if it fails?

No, because as I explained in my message, I don't think this should
be needed.  If the above assertion ever triggers, we will see what
kind of situation causes it, and can then discuss solutions.

bug#56561: 29.0.50; Infloop in try_window

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

Eli Zaretskii <eliz@gnu.org> writes:

> What I had in mind is an assertion in x-show-tip that the glyph matrix
> produced by try_window includes all of the tooltip text, i.e. that
> there's a glyph row there whose ends_at_zv_p flag is set.  This is an
> indication that all of the text was processed and will appear in the
> tooltip.
>
> Note that in the case in point this is precisely what's happened: the
> entire text of the tip was processed and produced its glyphs, and the
> problem happened while try_window was producing empty glyph rows
> beyond ZV.

Thanks, but we can't guarantee that the tooltip frame's window is large
enough to hold the entire contents of the tooltip buffer.  The size can
be changed (on various different platforms) by the window manager or the
toolkit.

> No, because as I explained in my message, I don't think this should
> be needed.  If the above assertion ever triggers, we will see what
> kind of situation causes it, and can then discuss solutions.

How about simply asserting that try_window never returns 0?

bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: mwd@md5i.com,  56561@debbugs.gnu.org
> Date: Sat, 16 Jul 2022 13:55:24 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What I had in mind is an assertion in x-show-tip that the glyph matrix
> > produced by try_window includes all of the tooltip text, i.e. that
> > there's a glyph row there whose ends_at_zv_p flag is set.  This is an
> > indication that all of the text was processed and will appear in the
> > tooltip.
> >
> > Note that in the case in point this is precisely what's happened: the
> > entire text of the tip was processed and produced its glyphs, and the
> > problem happened while try_window was producing empty glyph rows
> > beyond ZV.
> 
> Thanks, but we can't guarantee that the tooltip frame's window is large
> enough to hold the entire contents of the tooltip buffer.  The size can
> be changed (on various different platforms) by the window manager or the
> toolkit.

If the window manager changes the size of the window, we won't know
that in try_window, because the code which creates the window-system
window runs _after_ try_window.  The dimensions of the Emacs window
for which we invoke try_window and of its frame are determined by our
code:

  if (CONSP (Vx_max_tooltip_size)
      && RANGED_FIXNUMP (1, XCAR (Vx_max_tooltip_size), INT_MAX)
      && RANGED_FIXNUMP (1, XCDR (Vx_max_tooltip_size), INT_MAX))
    {
      w->total_cols = XFIXNAT (XCAR (Vx_max_tooltip_size));
      w->total_lines = XFIXNAT (XCDR (Vx_max_tooltip_size));
    }
  else
    {
      w->total_cols = 80;
      w->total_lines = 40;
    }

  w->pixel_width = w->total_cols * FRAME_COLUMN_WIDTH (tip_f);
  w->pixel_height = w->total_lines * FRAME_LINE_HEIGHT (tip_f);
  FRAME_TOTAL_COLS (tip_f) = WINDOW_TOTAL_COLS (w);
  adjust_frame_glyphs (tip_f);

Or maybe I don't understand what you mean by "the size can be changed
by the window manager", please explain and show the code to which you
allude.

As for toolkits: we don't use this code when toolkit tooltips are
used.

> > No, because as I explained in my message, I don't think this should
> > be needed.  If the above assertion ever triggers, we will see what
> > kind of situation causes it, and can then discuss solutions.
> 
> How about simply asserting that try_window never returns 0?

That would trigger unnecessarily, creating false positives.  The
situation that started this bug report is one such case: my fix will
cause try_window to return zero in that case.  But if the entire text
was processed and is in the glyph matrix, that zero return value
doesn't mean a failure.

bug#56561: 29.0.50; Infloop in try_window

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

Eli Zaretskii <eliz@gnu.org> writes:

>   if (CONSP (Vx_max_tooltip_size)
>       && RANGED_FIXNUMP (1, XCAR (Vx_max_tooltip_size), INT_MAX)
>       && RANGED_FIXNUMP (1, XCDR (Vx_max_tooltip_size), INT_MAX))
>     {
>       w->total_cols = XFIXNAT (XCAR (Vx_max_tooltip_size));
>       w->total_lines = XFIXNAT (XCDR (Vx_max_tooltip_size));
>     }
>   else
>     {
>       w->total_cols = 80;
>       w->total_lines = 40;
>     }
>
>   w->pixel_width = w->total_cols * FRAME_COLUMN_WIDTH (tip_f);
>   w->pixel_height = w->total_lines * FRAME_LINE_HEIGHT (tip_f);
>   FRAME_TOTAL_COLS (tip_f) = WINDOW_TOTAL_COLS (w);
>   adjust_frame_glyphs (tip_f);

Hmm, right.  But what if Vx_max_tooltip_size makes the window too small
to hold the entire tooltip?

> Or maybe I don't understand what you mean by "the size can be changed
> by the window manager", please explain and show the code to which you
> allude.
>
> As for toolkits: we don't use this code when toolkit tooltips are
> used.

I wasn't talking about X specifically.  The code in nsfns.m calls
[NSWindow setFrame: display:], which can end up calling
adjust_frame_size if NS decides for whatever reason to resize the
tooltip frame.

But you're right.  It is called after we compute the window dimensions
and then call try_window.

> That would trigger unnecessarily, creating false positives.

How so?  We pass TRY_WINDOW_IGNORE_FONTS_CHANGE, so try_window can only
return 0 if the glyph matrices are too small.

> The situation that started this bug report is one such case: my fix
> will cause try_window to return zero in that case.  But if the entire
> text was processed and is in the glyph matrix, that zero return value
> doesn't mean a failure.

That isn't what the comment above try_window says about its return
value:

   Value is 1 if successful.  It is zero if fonts were loaded during
   redisplay which makes re-adjusting glyph matrices necessary, and -1
   if point would appear in the scroll margins.
   (We check the former only if TRY_WINDOW_IGNORE_FONTS_CHANGE is
   unset in FLAGS, and the latter only if TRY_WINDOW_CHECK_MARGINS is
   set in FLAGS.)

bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: mwd@md5i.com,  56561@debbugs.gnu.org
> Date: Sat, 16 Jul 2022 14:42:09 +0800
> 
> Hmm, right.  But what if Vx_max_tooltip_size makes the window too small
> to hold the entire tooltip?

Then it's what the user or the application who set the values wanted,
and we shouldn't override that.  And in this case having try_window
return zero is perfectly OK, btw, even if it didn't process through
ZV.

> > As for toolkits: we don't use this code when toolkit tooltips are
> > used.
> 
> I wasn't talking about X specifically.  The code in nsfns.m calls
> [NSWindow setFrame: display:], which can end up calling
> adjust_frame_size if NS decides for whatever reason to resize the
> tooltip frame.

Depending on the conditions when that resizing happens, it could
arguably be a bug, e.g. if x-max-tooltip-size restriction is
overruled.

> > That would trigger unnecessarily, creating false positives.
> 
> How so?  We pass TRY_WINDOW_IGNORE_FONTS_CHANGE, so try_window can only
> return 0 if the glyph matrices are too small.

The question is "small for what?"  If it is only too small to display
enough empty glyph rows, we don't care, since the tooltip will be
sized to accommodate for the text part only, and the empty glyph rows
will not be displayed anyway.

> > The situation that started this bug report is one such case: my fix
> > will cause try_window to return zero in that case.  But if the entire
> > text was processed and is in the glyph matrix, that zero return value
> > doesn't mean a failure.
> 
> That isn't what the comment above try_window says about its return
> value:
> 
>    Value is 1 if successful.  It is zero if fonts were loaded during
>    redisplay which makes re-adjusting glyph matrices necessary, and -1
>    if point would appear in the scroll margins.
>    (We check the former only if TRY_WINDOW_IGNORE_FONTS_CHANGE is
>    unset in FLAGS, and the latter only if TRY_WINDOW_CHECK_MARGINS is
>    set in FLAGS.)

I'm reading the code, not the commentary.  I will fix the commentary
to be more accurate: it doesn't take into account the special way we
invoke this function from x-show-tip.  Note that x-show-tip doesn't
check the return value, and never did, for that very reason.

bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> Cc: mwd@md5i.com, 56561@debbugs.gnu.org
> Date: Sat, 16 Jul 2022 10:32:30 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > > The situation that started this bug report is one such case: my fix
> > > will cause try_window to return zero in that case.  But if the entire
> > > text was processed and is in the glyph matrix, that zero return value
> > > doesn't mean a failure.
> > 
> > That isn't what the comment above try_window says about its return
> > value:
> > 
> >    Value is 1 if successful.  It is zero if fonts were loaded during
> >    redisplay which makes re-adjusting glyph matrices necessary, and -1
> >    if point would appear in the scroll margins.
> >    (We check the former only if TRY_WINDOW_IGNORE_FONTS_CHANGE is
> >    unset in FLAGS, and the latter only if TRY_WINDOW_CHECK_MARGINS is
> >    set in FLAGS.)
> 
> I'm reading the code, not the commentary.  I will fix the commentary
> to be more accurate

Now done.

bug#56561: 29.0.50; Infloop in try_window

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

Eli Zaretskii <eliz@gnu.org> writes:

> Then it's what the user or the application who set the values wanted,
> and we shouldn't override that.  And in this case having try_window
> return zero is perfectly OK, btw, even if it didn't process through
> ZV.

The point I was making was that aborting in such a situation (when there
is no row where ends_at_zv_p is true) will result in false positives
when the tooltip is intentionally too small to display the entire text.

> I'm reading the code, not the commentary.  I will fix the commentary
> to be more accurate: it doesn't take into account the special way we
> invoke this function from x-show-tip.

Thanks.

bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: mwd@md5i.com,  56561@debbugs.gnu.org
> Date: Sat, 16 Jul 2022 16:47:19 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Then it's what the user or the application who set the values wanted,
> > and we shouldn't override that.  And in this case having try_window
> > return zero is perfectly OK, btw, even if it didn't process through
> > ZV.
> 
> The point I was making was that aborting in such a situation (when there
> is no row where ends_at_zv_p is true) will result in false positives
> when the tooltip is intentionally too small to display the entire text.

Yes, and so this situation should be detected, and we should avoid
triggering the assertion violation in that case.

bug#56561: 29.0.50; Infloop in try_window

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

Eli Zaretskii <eliz@gnu.org> writes:

>> The point I was making was that aborting in such a situation (when there
>> is no row where ends_at_zv_p is true) will result in false positives
>> when the tooltip is intentionally too small to display the entire text.

> Yes, and so this situation should be detected, and we should avoid
> triggering the assertion violation in that case.

Hmm.  I might've missed where you explained that, but how would I go
about detecting that situation?

The way I understand the code is that we set the window dimensions to
the max tooltip size, create a glyph matrix of that size, and then call
try_window.

Thanks.

bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: mwd@md5i.com,  56561@debbugs.gnu.org
> Date: Sat, 16 Jul 2022 18:34:17 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The point I was making was that aborting in such a situation (when there
> >> is no row where ends_at_zv_p is true) will result in false positives
> >> when the tooltip is intentionally too small to display the entire text.
> 
> > Yes, and so this situation should be detected, and we should avoid
> > triggering the assertion violation in that case.
> 
> Hmm.  I might've missed where you explained that, but how would I go
> about detecting that situation?
> 
> The way I understand the code is that we set the window dimensions to
> the max tooltip size, create a glyph matrix of that size, and then call
> try_window.

That is true.  Which part of detecting the above situation sounds
problematic to you?  I'm asking because I'm uncertain what should I
explain in this regard.

bug#56561: 29.0.50; Infloop in try_window

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

Eli Zaretskii <eliz@gnu.org> writes:

> That is true.  Which part of detecting the above situation sounds
> problematic to you?  I'm asking because I'm uncertain what should I
> explain in this regard.

The problem is how to detect that the glyph matrix is indeed too small
to fit all of the tooltip text, and not too small due to the bug being
triggered?  The size calculated later on is not useful: it is returned
in pixels, and doesn't take into account any line wrapping (or other
similar operations) try_window might perform.

bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: mwd@md5i.com,  56561@debbugs.gnu.org
> Date: Sat, 16 Jul 2022 19:07:26 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That is true.  Which part of detecting the above situation sounds
> > problematic to you?  I'm asking because I'm uncertain what should I
> > explain in this regard.
> 
> The problem is how to detect that the glyph matrix is indeed too small
> to fit all of the tooltip text, and not too small due to the bug being
> triggered?

Which bug? the one which started this discussion? that's the idea of
looking at ends_at_zv_p flag of the rows in the matrix, after
try_window returns.

bug#56561: 29.0.50; Infloop in try_window

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

Eli Zaretskii <eliz@gnu.org> writes:

>> The problem is how to detect that the glyph matrix is indeed too small
>> to fit all of the tooltip text, and not too small due to the bug being
>> triggered?

> Which bug? the one which started this discussion? that's the idea of
> looking at ends_at_zv_p flag of the rows in the matrix, after
> try_window returns.

Yes.  The question was how to tell apart the situation where the rows
don't extend to ZV because of that bug, and when they don't extend to ZV
legitimately (since the tooltip is too small.)

bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: mwd@md5i.com,  56561@debbugs.gnu.org
> Date: Sat, 16 Jul 2022 20:34:57 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The problem is how to detect that the glyph matrix is indeed too small
> >> to fit all of the tooltip text, and not too small due to the bug being
> >> triggered?
> 
> > Which bug? the one which started this discussion? that's the idea of
> > looking at ends_at_zv_p flag of the rows in the matrix, after
> > try_window returns.
> 
> Yes.  The question was how to tell apart the situation where the rows
> don't extend to ZV because of that bug, and when they don't extend to ZV
> legitimately (since the tooltip is too small.)

By "legitimately", you mean because of the restrictions in
x-max-tooltip-size?  I guess we should compare the values of
x-max-tooltip-size with their default values.

bug#56561: 29.0.50; Infloop in try_window

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

Eli Zaretskii <eliz@gnu.org> writes:

>> Yes.  The question was how to tell apart the situation where the rows
>> don't extend to ZV because of that bug, and when they don't extend to ZV
>> legitimately (since the tooltip is too small.)
>
> By "legitimately", you mean because of the restrictions in
> x-max-tooltip-size?  I guess we should compare the values of
> x-max-tooltip-size with their default values.

Indeed.  But the default is 80 by 40, so a restriction is still placed.
So unfortunately that doesn't seem very helpful.

bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: mwd@md5i.com,  56561@debbugs.gnu.org
> Date: Sun, 17 Jul 2022 08:45:56 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Yes.  The question was how to tell apart the situation where the rows
> >> don't extend to ZV because of that bug, and when they don't extend to ZV
> >> legitimately (since the tooltip is too small.)
> >
> > By "legitimately", you mean because of the restrictions in
> > x-max-tooltip-size?  I guess we should compare the values of
> > x-max-tooltip-size with their default values.
> 
> Indeed.  But the default is 80 by 40, so a restriction is still placed.
> So unfortunately that doesn't seem very helpful.

I don't see the problem.  If the default causes only partial display
(which would really need a HUGE tooltip), then whoever does that
without adjusting x-max-tooltip-size has only him/herself to blame,
and I see no problem.

We were talking about the conditions for an assertion.  Assertions are
for developers, they are compiled to nothing in a production build, so
such bad code in a production build will show a partial text.  While
in a development build, we will in such a case see an assertion, which
will tell us some code needs to be fixed.  Where's the problem?

bug#56561: 29.0.50; Infloop in try_window

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

Eli Zaretskii <eliz@gnu.org> writes:

> I don't see the problem.  If the default causes only partial display
> (which would really need a HUGE tooltip), then whoever does that
> without adjusting x-max-tooltip-size has only him/herself to blame,
> and I see no problem.
>
> We were talking about the conditions for an assertion.  Assertions are
> for developers, they are compiled to nothing in a production build, so
> such bad code in a production build will show a partial text.  While
> in a development build, we will in such a case see an assertion, which
> will tell us some code needs to be fixed.  Where's the problem?

Because the assertion will cause annoying behavior with big tooltips in
a build with checking.  Big tooltips appear all the time: moving the
mouse over a link to a long enough URL in eww will cause one to be
displayed, for example.

bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: mwd@md5i.com,  56561@debbugs.gnu.org
> Date: Sun, 17 Jul 2022 14:29:28 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't see the problem.  If the default causes only partial display
> > (which would really need a HUGE tooltip), then whoever does that
> > without adjusting x-max-tooltip-size has only him/herself to blame,
> > and I see no problem.
> >
> > We were talking about the conditions for an assertion.  Assertions are
> > for developers, they are compiled to nothing in a production build, so
> > such bad code in a production build will show a partial text.  While
> > in a development build, we will in such a case see an assertion, which
> > will tell us some code needs to be fixed.  Where's the problem?
> 
> Because the assertion will cause annoying behavior with big tooltips in
> a build with checking.  Big tooltips appear all the time: moving the
> mouse over a link to a long enough URL in eww will cause one to be
> displayed, for example.

More than 40 screen lines of canonical characters?  Please show a
recipe for reproducing this.

bug#56561: 29.0.50; Infloop in try_window

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

Eli Zaretskii <eliz@gnu.org> writes:

> More than 40 screen lines of canonical characters?  Please show a
> recipe for reproducing this.

Place the following text in a buffer

<a href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAHgAAAB4CAIAAAC2BqGFAAABhWlDQ1BJQ0MgcHJvZmlsZQAAKJF9kT1Iw1AUhU9TpSIVETuIOGSo4mChqIijVqEIFUKt0KqDyUt/hCYNSYqLo+BacPBnserg4qyrg6sgCP6AODo5KbpIifclhRYxPri8j/PeOdx3HyDUy0yzOuKApttmOpkQs7kVMfSKEPqoRhGXmWXMSlIKvuvrHgG+38V4lv+9P1ePmrcYEBCJZ5hh2sTrxFObtsF5nzjCSrJKfE48ZlKDxI9cVzx+41x0WeCZETOTniOOEIvFNlbamJVMjXiSOKpqOuULWY9VzluctXKVNfvkLwzn9eUlrlMNIYkFLEKCCAVVbKAMGzHadVIspOk84eMfdP0SuRRybYCRYx4VaJBdP/gf/J6tVZgY95LCCaDzxXE+hoHQLtCoOc73seM0ToDgM3Clt/yVOjD9SXqtpUWPgN5t4OK6pSl7wOUOMPBkyKbsSkEqoVAA3s/om3JA/y3QverNrXmO0wcgQ7NK3QAHh8BIkbLXfN7d1T63f+805/cDmFJytmmECVUAAAAJcEhZcwAALiMAAC4jAXilP3YAAAAHdElNRQfmBxEHKRAK8iffAAAAGXRFWHRDb21tZW50AENyZWF0ZWQgd2l0aCBHSU1QV4EOFwAAC6ZJREFUeNrtnW1z2kYQgHfvRQhhAsR1XsBpM9OmH/r/f0tnmqSZNDbYietgCkhIurvthwMhCMYkFnCyuQ+ZjA0YPZxXe8/trZGI4DC2P9gBwQH0AfRhHEAfQB9AH8ZOhsj+Z5JEjcfJzY0KQwAQQeA1m6JWY553wLR+bIIObR5tkiTsdpPBgNI0/xKy0Th6/frAej3l0ceP6WCQ/yJK6TUaQaeToRNLlI1SlCREBEQAoEYjE8dPfv+dVSoHpispD9+9i6+vlygzgGQwAICMtQAANR7nKZskIa2BgMgAQHh2xiqV+m+/ITsE9MVBFJ6djf/5Z8oXGSBYrAbAsvaaTS8DndzcLFE2SQLGEBEYAwDj9+9FvV599gw5P+CdQjYm/vff4V9/mSgCAGAMEYGxLMGYsr658Vqt2YwOQwCYsp5Rns5rY4xSajSKzs9JqeqLF0zKA2XSOvryJf7yJe33LWVARMaY55kkmSdzQli2C1kHAJBSpFRG2RIHY0gpHUWTy0vSuvryJX/c8Zq0jj5/jq+udBiaOAZESxk8zyQJ8zxSyiByIZbzaBEE+VfJz2sbTFAIHUU6iuKrq7Db1ZPJgbIOQx1FgGiShNKUjKEkIWMsvXn6PGPLAMBrNhdebDav7TMpTVF6dlLrKEqur8Pz88fJ2qRp2OtF3W46GKT//aejCLmYUrb/KgVK5Z+SsRUAIGo12WhoG9RnkZ6UmlGWzJMmjhmAfUwCAADB6Sn3/cdDWcdxdHERX13ZCUdKmThmnkTOKU1BSlAKECEXMWSjIWq1OWjmeUevX1Oaht1u7uMzpDVKKVst9DwbuB8taz2ZhL1ecn2dpwzGoOfJVivt96cTOZcpVI6P82u9KX7mefU3b0StNnz71uYrzPd5rYaeh0KAMcAYGGPiGGcBKAEgrYNXr/Ih/sFSPj9P+v05ZZsmMDZlfXxMSUJa280qXq0evXmTXxbOl+DZSAaDsNvV47F9URNFZIxNzmfPQBSCVSq8WuXVqnzypNrpyKOjR0cZccoaABlj1aoFwmu1oN1evu0tpXcA4DUayFjU681DSByD1vPPgwi0NnG88LR2W9brj4sy0WrKnY7XaKyzd/MQXq9Dp7Nwt41jmNkPACAiUMrYmW4foPVtP+DBUkZEROA8++UW9XrQ6dw24cTKr8qjI3z1Kjw7m6MEIKXsD7C/MmSMySUqYbcLRN/+yhworwNtM+3aL7+E5+dJlvNxbpIEtLY3gTlrmwsqNVaKtK48fQqID4wypWoNZfnkSfWu4CnWfI/7fnB6miVzOoqYDSOzGy4wRkqZ3FPC83PSuvLTT+VVfSspk9HrKG+QDoj1317PmpRCIZZYRxcXRuuSqj4VhuHZmV316ShaTgRWUd4wwRV3PmLKmrHk+jrPmoyxlFEI0lpHERlj0tSkqUmSMqq+dDSKut0VlO2dCQAZRylQCEvZa7U2X7KJTR7EfT/odJCx+OrqW9bzeJ1bppdO9aXDYdTr3UqZCLn4YcqbggYAXqkEnQ5yPrm8XIghRPMYssg6vroiY4J22/1lejocht2uGg5vowyM3Yfyd4AGACZl0G6jEPGXL0xKHUXImInjLFLb2b2gn66vwRjHlcgmlJnn3Yfy94EGAOS8+vw54zy6uFhKsZeUSFn00zrlUBzl7wZtV5z+yQlynld9BoByOV9ZVF9ycxP2eiso26sojvKPgLZZTuX4GDkPez0UQgsBjE3fZZ6126ov6ffDi4tbKRsDnBdF+UdBW/3UbALiwrzOWNvEk2h5OXN25ojqS/r9sNez21GW8uwa5nNlgfLx8T3v6uI+b7eUqo8o/vo1PD+3lE0cL7y9jHKlklGunJzcP08V93zb5VJ9thgjurjIUyZrb4iQMfqGsv/iRSErL3H/d18W1ZcVY6ygrDVwTsYgY6xSma6wg6ByclJ9/rwQlyAKuQb3Vd9SmcC3lMEY5HxLlAsD7bjqW03ZvrHbKD97VqwXEwVej5uqz6RpdHk5ubxc2MAGmEbkVZSrL18W/vGLYq/KNdW3shgjC2VTlIuUg9PTbQQ0Ufi1uaP6bivGmK+qbEaXba0GQdBu2+LPwofYxou6oPrWF2OsoFyrBS9fbonytkDvXfVtQnmTYowSgN6j6iuwGKMcoPei+govEygH6B2rPmcp7wT0rlTfNooxygd626pvS8UYpQS9PdW3vWKMsoLehurbajFGiUEXq/q2XYxRbtBFqb4dFGOUHvT9Vd9uijEeAuj7qD4RBNHnzzsoxihyObH3dmwrTebUYeZ8ZraPR0qR1jwI7Gew1WKMBwUabnPzRICYqT7L2kwmejQCIvR9UauR1lstxnhooOG2nVOlsngNxugw1KMRzY6mopTy+Djvp5Y2sO9fjPFAYvR3qD6tdRimV1cmTe0CEhCxUgEieXyMUm6pGOMBgl6n+pRSo5G6vjZpSpMJaW2jCgPQxgCAZb2NYoyHCXql6iOA9OtX1e9PKStFSQIEKLiJIgagh0MwpnJ6mm1HFVsmUNRw8UiP12wGnQ6v1ZjnmSgykwmlKcXxjDIBAqUpaD39ltZqMAAAZymDs33vvEYjaLcpTafSw2qQJSWiNWgNRGQMaa2GQx4EblJ2F7RJ03Q4JGOspwYiIiLbtMhuR1nimc4G4L6v4zgdjdy8IhdB6zgOu93J5SUg8nqdVSqAiFKilMAYMAaAwBgKgVKClAjA63Xm+yaKwm43ublx8KKEc5QXizFQCNFs2raHU+9hjM35mO+jlOj74ulTJqUOQ9La2QO8wjnK32z6Iefy5GS6rkGkNMVKBRFRSlatimaTHx25f4BXOE7Z3vcQQJ6cAKIJQ/B9AkAhkDHRbPJ6vRQHeF1Zgt+5gW2X6Xo8JrupiChaLZwVNU8XkHYh4+TKxQnQm5cJIOd6PDZJIup1q5zWqz531uIOaNLvLMbgvo9CqNHoTtXnlF0SrlHepBhDBIFVfSU6wCtco7xhMUbpDvDuDfQ9izFKd4B3P6CLKcYo1QHePYAuthijLAd4xe4pF16MUYoDvMI1yj+2ter+Ad7dgd52ZwzHD/DuCPRuOmO4fIB3F6B32RnD2QO8YheUd9sZw80DvNsEvafOGOBkr75tgd5jZ4w5a5d69W0F9H47Y8xZu9SrT2yF8l47Y+SHO736xC4o77YzxrJxd6NXX5GgHemMsYK1A6qvMNDudMa4BfaeVV8xoJ3qjLFOP+1P9YliKLvUGeMO1ntSfWIHlHfcGcNN1Se2QnmvnTHcVH1iW5T32rPBQdUnHifl3as+UQhlpzpjuKn6RCGUneqM4abq+z7QpeiM4abq+w7QZemM4abq2xR0iTpjuKn6xIaUS9QZw03VJwqh7OY5d6dU3x2gd/ZnShyDXbzqWwd6l3+mxMFRrOq7FfR/794N//zTnhC2GyW8XheNhvudMdxUfatBjz5+HH/4ALlTF8i5HgzAGNFqbaMYw9lRlOpbATrsdsNPnxaTTI5EZIweDgFAtFoud8ZwU/WtAJ3/TQEAEAIBiIgBGAA9HHovXrjcGWNfqi/t9/WnT3avjvn++N27+h9/PHnzZrP0TggkAmNASgJgACSl450x9qKfVL+vh0MQOZ5E4w8fmJRHr1/fARqFYADT6JOmIKXl/ggpr2c9pcwYcg6L+jT89IlJGXQ6t4JmQhgiMoZ5nkkSAECb2Nn+I1suxiiX6ptSlhIZQyEW5jVA1OvdChqFgFmLCZMkzPPIBhAAANhNMUaJVJ/tb4GMoech58j5EuvVoaPabke9noXKshRmls3Ufv3VPzkp+59YL1b1oRAohA0dKCVyzuxX1oMOOh074S1rnssogp9/tqH9MPKqj9uloN2M5px5nu3bwnKsV4eOjDXkKFfb7WAxdX/kI1N94/fvZ/gZItrVHJMSpczmtSttJEo8iAZv347//nvmoxAQM8pMSjtBD6CLGaOPH5eW03nKhxld5Ai73aVFdT7YHkDv6uZ5QLCb8T+jZg5A8TH4MwAAAABJRU5ErkJggg==">View image</a>

and type "M-x shr-render-buffer RET".  The tooltip on top of "View
image" will be larger than the size limit.

bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: mwd@md5i.com,  56561@debbugs.gnu.org
> Date: Sun, 17 Jul 2022 15:43:00 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > More than 40 screen lines of canonical characters?  Please show a
> > recipe for reproducing this.
> 
> Place the following text in a buffer
> 
> <a href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAHgAAAB4CAIAAAC2BqGFAAABhWlDQ1BJQ0MgcHJvZmlsZQAAKJF9kT1Iw1AUhU9TpSIVETuIOGSo4mChqIijVqEIFUKt0KqDyUt/hCYNSYqLo+BacPBnserg4qyrg6sgCP6AODo5KbpIifclhRYxPri8j/PeOdx3HyDUy0yzOuKApttmOpkQs7kVMfSKEPqoRhGXmWXMSlIKvuvrHgG+38V4lv+9P1ePmrcYEBCJZ5hh2sTrxFObtsF5nzjCSrJKfE48ZlKDxI9cVzx+41x0WeCZETOTniOOEIvFNlbamJVMjXiSOKpqOuULWY9VzluctXKVNfvkLwzn9eUlrlMNIYkFLEKCCAVVbKAMGzHadVIspOk84eMfdP0SuRRybYCRYx4VaJBdP/gf/J6tVZgY95LCCaDzxXE+hoHQLtCoOc73seM0ToDgM3Clt/yVOjD9SXqtpUWPgN5t4OK6pSl7wOUOMPBkyKbsSkEqoVAA3s/om3JA/y3QverNrXmO0wcgQ7NK3QAHh8BIkbLXfN7d1T63f+805/cDmFJytmmECVUAAAAJcEhZcwAALiMAAC4jAXilP3YAAAAHdElNRQfmBxEHKRAK8iffAAAAGXRFWHRDb21tZW50AENyZWF0ZWQgd2l0aCBHSU1QV4EOFwAAC6ZJREFUeNrtnW1z2kYQgHfvRQhhAsR1XsBpM9OmH/r/f0tnmqSZNDbYietgCkhIurvthwMhCMYkFnCyuQ+
 ZjA0YPZxXe8/trZGI4DC2P9gBwQH0AfRhHEAfQB9AH8ZOhsj+Z5JEjcfJzY0KQwAQQeA1m6JWY553wLR+bIIObR5tkiTsdpPBgNI0/xKy0Th6/frAej3l0ceP6WCQ/yJK6TUaQaeToRNLlI1SlCREBEQAoEYjE8dPfv+dVSoHpispD9+9i6+vlygzgGQwAICMtQAANR7nKZskIa2BgMgAQHh2xiqV+m+/ITsE9MVBFJ6djf/5Z8oXGSBYrAbAsvaaTS8DndzcLFE2SQLGEBEYAwDj9+9FvV599gw5P+CdQjYm/vff4V9/mSgCAGAMEYGxLMGYsr658Vqt2YwOQwCYsp5Rns5rY4xSajSKzs9JqeqLF0zKA2XSOvryJf7yJe33LWVARMaY55kkmSdzQli2C1kHAJBSpFRG2RIHY0gpHUWTy0vSuvryJX/c8Zq0jj5/jq+udBiaOAZESxk8zyQJ8zxSyiByIZbzaBEE+VfJz2sbTFAIHUU6iuKrq7Db1ZPJgbIOQx1FgGiShNKUjKEkIWMsvXn6PGPLAMBrNhdebDav7TMpTVF6dlLrKEqur8Pz88fJ2qRp2OtF3W46GKT//aejCLmYUrb/KgVK5Z+SsRUAIGo12WhoG9RnkZ6UmlGWzJMmjhmAfUwCAADB6Sn3/cdDWcdxdHERX13ZCUdKmThmnkTOKU1BSlAKECEXMWSjIWq1OWjmeUevX1Oaht1u7uMzpDVKKVst9DwbuB8taz2ZhL1ecn2dpwzGoOfJVivt96cTOZcpVI6P82u9KX7mefU3b0StN
 nz71uYrzPd5rYaeh0KAMcAYGGPiGGcBKAEgrYNXr/Ih/sFSPj9P+v05ZZsmMDZlfXxMSUJa280qXq0evXmTXxbOl+DZSAaDsNvV47F9URNFZIxNzmfPQBSCVSq8WuXVqnzypNrpyKOjR0cZccoaABlj1aoFwmu1oN1evu0tpXcA4DUayFjU681DSByD1vPPgwi0NnG88LR2W9brj4sy0WrKnY7XaKyzd/MQXq9Dp7Nwt41jmNkPACAiUMrYmW4foPVtP+DBUkZEROA8++UW9XrQ6dw24cTKr8qjI3z1Kjw7m6MEIKXsD7C/MmSMySUqYbcLRN/+yhworwNtM+3aL7+E5+dJlvNxbpIEtLY3gTlrmwsqNVaKtK48fQqID4wypWoNZfnkSfWu4CnWfI/7fnB6miVzOoqYDSOzGy4wRkqZ3FPC83PSuvLTT+VVfSspk9HrKG+QDoj1317PmpRCIZZYRxcXRuuSqj4VhuHZmV316ShaTgRWUd4wwRV3PmLKmrHk+jrPmoyxlFEI0lpHERlj0tSkqUmSMqq+dDSKut0VlO2dCQAZRylQCEvZa7U2X7KJTR7EfT/odJCx+OrqW9bzeJ1bppdO9aXDYdTr3UqZCLn4YcqbggYAXqkEnQ5yPrm8XIghRPMYssg6vroiY4J22/1lejocht2uGg5vowyM3Yfyd4AGACZl0G6jEPGXL0xKHUXImInjLFLb2b2gn66vwRjHlcgmlJnn3Yfy94EGAOS8+vw54zy6uFhKsZeUSFn00zrlUBzl7wZtV5z+yQlynld9BoB
 yOV9ZVF9ycxP2eiso26sojvKPgLZZTuX4GDkPez0UQgsBjE3fZZ6126ov6ffDi4tbKRsDnBdF+UdBW/3UbALiwrzOWNvEk2h5OXN25ojqS/r9sNez21GW8uwa5nNlgfLx8T3v6uI+b7eUqo8o/vo1PD+3lE0cL7y9jHKlklGunJzcP08V93zb5VJ9thgjurjIUyZrb4iQMfqGsv/iRSErL3H/d18W1ZcVY6ygrDVwTsYgY6xSma6wg6ByclJ9/rwQlyAKuQb3Vd9SmcC3lMEY5HxLlAsD7bjqW03ZvrHbKD97VqwXEwVej5uqz6RpdHk5ubxc2MAGmEbkVZSrL18W/vGLYq/KNdW3shgjC2VTlIuUg9PTbQQ0Ufi1uaP6bivGmK+qbEaXba0GQdBu2+LPwofYxou6oPrWF2OsoFyrBS9fbonytkDvXfVtQnmTYowSgN6j6iuwGKMcoPei+govEygH6B2rPmcp7wT0rlTfNooxygd626pvS8UYpQS9PdW3vWKMsoLehurbajFGiUEXq/q2XYxRbtBFqb4dFGOUHvT9Vd9uijEeAuj7qD4RBNHnzzsoxihyObH3dmwrTebUYeZ8ZraPR0qR1jwI7Gew1WKMBwUabnPzRICYqT7L2kwmejQCIvR9UauR1lstxnhooOG2nVOlsngNxugw1KMRzY6mopTy+Djvp5Y2sO9fjPFAYvR3qD6tdRimV1cmTe0CEhCxUgEieXyMUm6pGOMBgl6n+pRSo5G6vjZpSpMJaW2jCgPQxgCAZb2NYoyHCXql6iOA9OtX1
 e9PKStFSQIEKLiJIgagh0MwpnJ6mm1HFVsmUNRw8UiP12wGnQ6v1ZjnmSgykwmlKcXxjDIBAqUpaD39ltZqMAAAZymDs33vvEYjaLcpTafSw2qQJSWiNWgNRGQMaa2GQx4EblJ2F7RJ03Q4JGOspwYiIiLbtMhuR1nimc4G4L6v4zgdjdy8IhdB6zgOu93J5SUg8nqdVSqAiFKilMAYMAaAwBgKgVKClAjA63Xm+yaKwm43ublx8KKEc5QXizFQCNFs2raHU+9hjM35mO+jlOj74ulTJqUOQ9La2QO8wjnK32z6Iefy5GS6rkGkNMVKBRFRSlatimaTHx25f4BXOE7Z3vcQQJ6cAKIJQ/B9AkAhkDHRbPJ6vRQHeF1Zgt+5gW2X6Xo8JrupiChaLZwVNU8XkHYh4+TKxQnQm5cJIOd6PDZJIup1q5zWqz531uIOaNLvLMbgvo9CqNHoTtXnlF0SrlHepBhDBIFVfSU6wCtco7xhMUbpDvDuDfQ9izFKd4B3P6CLKcYo1QHePYAuthijLAd4xe4pF16MUYoDvMI1yj+2ter+Ad7dgd52ZwzHD/DuCPRuOmO4fIB3F6B32RnD2QO8YheUd9sZw80DvNsEvafOGOBkr75tgd5jZ4w5a5d69W0F9H47Y8xZu9SrT2yF8l47Y+SHO736xC4o77YzxrJxd6NXX5GgHemMsYK1A6qvMNDudMa4BfaeVV8xoJ3qjLFOP+1P9YliKLvUGeMO1ntSfWIHlHfcGcNN1Se2QnmvnTHcVH1iW5T32rPBQdUnHifl3as
 +UQhlpzpjuKn6RCGUneqM4abq+z7QpeiM4abq+w7QZemM4abq2xR0iTpjuKn6xIaUS9QZw03VJwqh7OY5d6dU3x2gd/ZnShyDXbzqWwd6l3+mxMFRrOq7FfR/794N//zTnhC2GyW8XheNhvudMdxUfatBjz5+HH/4ALlTF8i5HgzAGNFqbaMYw9lRlOpbATrsdsNPnxaTTI5EZIweDgFAtFoud8ZwU/WtAJ3/TQEAEAIBiIgBGAA9HHovXrjcGWNfqi/t9/WnT3avjvn++N27+h9/PHnzZrP0TggkAmNASgJgACSl450x9qKfVL+vh0MQOZ5E4w8fmJRHr1/fARqFYADT6JOmIKXl/ggpr2c9pcwYcg6L+jT89IlJGXQ6t4JmQhgiMoZ5nkkSAECb2Nn+I1suxiiX6ptSlhIZQyEW5jVA1OvdChqFgFmLCZMkzPPIBhAAANhNMUaJVJ/tb4GMoech58j5EuvVoaPabke9noXKshRmls3Ufv3VPzkp+59YL1b1oRAohA0dKCVyzuxX1oMOOh074S1rnssogp9/tqH9MPKqj9uloN2M5px5nu3bwnKsV4eOjDXkKFfb7WAxdX/kI1N94/fvZ/gZItrVHJMSpczmtSttJEo8iAZv347//nvmoxAQM8pMSjtBD6CLGaOPH5eW03nKhxld5Ai73aVFdT7YHkDv6uZ5QLCb8T+jZg5A8TH4MwAAAABJRU5ErkJggg==">View image</a>
> 
> and type "M-x shr-render-buffer RET".  The tooltip on top of "View
> image" will be larger than the size limit.

Thanks.  The patch below is what I had in mind.  WDYT?

diff --git a/src/w32fns.c b/src/w32fns.c
index 51540e1..5e42a1d 100644
--- a/src/w32fns.c
+++ b/src/w32fns.c
@@ -7568,7 +7568,23 @@ DEFUN ("x-show-tip", Fx_show_tip, Sx_show_tip, 1, 6, 0,
   clear_glyph_matrix (w->desired_matrix);
   clear_glyph_matrix (w->current_matrix);
   SET_TEXT_POS (pos, BEGV, BEGV_BYTE);
-  try_window (window, pos, TRY_WINDOW_IGNORE_FONTS_CHANGE);
+  bool displayed = try_window (window, pos, TRY_WINDOW_IGNORE_FONTS_CHANGE);
+  if (!displayed && NILP (Vx_max_tooltip_size))
+    {
+#ifdef ENABLE_CHECKING
+      struct glyph_row *row = w->desired_matrix->rows;
+      struct glyph_row *end =
+	w->desired_matrix->rows + w->desired_matrix->nrows;
+      while (row < end)
+	{
+	  if (!row->displays_text_p
+	      || row->ends_at_zv_p)
+	    break;
+	  ++row;
+	}
+      eassert (row < end && row->ends_at_zv_p);
+#endif
+    }
   /* Calculate size of tooltip window.  */
   size = Fwindow_text_pixel_size (window, Qnil, Qnil, Qnil,
 				  make_fixnum (w->pixel_height), Qnil,
@@ -10770,7 +10786,7 @@ syms_of_w32fns (void)
 
   DEFVAR_LISP ("x-max-tooltip-size", Vx_max_tooltip_size,
 	       doc: /* SKIP: real doc in xfns.c.  */);
-  Vx_max_tooltip_size = Fcons (make_fixnum (80), make_fixnum (40));
+  Vx_max_tooltip_size = Qnil;
 
   DEFVAR_LISP ("x-no-window-manager", Vx_no_window_manager,
 	       doc: /* SKIP: real doc in xfns.c.  */);

bug#56561: 29.0.50; Infloop in try_window

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

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks.  The patch below is what I had in mind.  WDYT?

It works fine (though we should make the change in all the *fns.[cm]
files).  But I don't see the strict requirement for this change:

>    DEFVAR_LISP ("x-max-tooltip-size", Vx_max_tooltip_size,
>  	       doc: /* SKIP: real doc in xfns.c.  */);
> -  Vx_max_tooltip_size = Fcons (make_fixnum (80), make_fixnum (40));
> +  Vx_max_tooltip_size = Qnil;
>  
>    DEFVAR_LISP ("x-no-window-manager", Vx_no_window_manager,
>  	       doc: /* SKIP: real doc in xfns.c.  */);

Thanks.

bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: mwd@md5i.com,  56561@debbugs.gnu.org
> Date: Mon, 18 Jul 2022 08:57:08 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Thanks.  The patch below is what I had in mind.  WDYT?
> 
> It works fine (though we should make the change in all the *fns.[cm]
> files).

Sure, what I posted was only a proof of concept.

> But I don't see the strict requirement for this change:
> 
> >    DEFVAR_LISP ("x-max-tooltip-size", Vx_max_tooltip_size,
> >  	       doc: /* SKIP: real doc in xfns.c.  */);
> > -  Vx_max_tooltip_size = Fcons (make_fixnum (80), make_fixnum (40));
> > +  Vx_max_tooltip_size = Qnil;
> >  
> >    DEFVAR_LISP ("x-no-window-manager", Vx_no_window_manager,
> >  	       doc: /* SKIP: real doc in xfns.c.  */);

This makes it easier to distinguish between the default value and a
non-default value.  I also don't see any reason to have the default
both as a cons cell and as hard-coded values.

bug#56561: 29.0.50; Infloop in try_window

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

Eli Zaretskii <eliz@gnu.org> writes:

> This makes it easier to distinguish between the default value and a
> non-default value.  I also don't see any reason to have the default
> both as a cons cell and as hard-coded values.

Sounds reasonable to me, thanks.

bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: mwd@md5i.com,  56561@debbugs.gnu.org
> Date: Tue, 19 Jul 2022 08:54:59 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This makes it easier to distinguish between the default value and a
> > non-default value.  I also don't see any reason to have the default
> > both as a cons cell and as hard-coded values.
> 
> Sounds reasonable to me, thanks.

I installed the change for the w32 build.  Would you mind installing
the same for the other GUI environments?  I'd prefer not to make
changes I cannot compile, let alone test, if I can avoid that.

Thanks.

bug#56561: 29.0.50; Infloop in try_window

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

Eli Zaretskii <eliz@gnu.org> writes:

> I installed the change for the w32 build.  Would you mind installing
> the same for the other GUI environments?  I'd prefer not to make
> changes I cannot compile, let alone test, if I can avoid that.

Sure, will do.