Subject: Re: bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

From: Gerd Möllmann <[email-masked]>
Date: Thu, 23 Jan 2025 18:34:25 +0100

Eli Zaretskii <[email-masked]> writes:

>> From: Len Trigg <[email-masked]>
>> Date: Fri, 24 Jan 2025 05:00:33 +1300
>> Cc: [email-masked], [email-masked]
>> 
>> #0  combine_updates_for_frame (f=f@entry=0x555556ca8d58,
>> inhibit_scrolling=inhibit_scrolling@entry=false) at dispnew.c:3973
>
> The crash is here:
>
>   for (Lisp_Object tail = XCDR (z_order); CONSP (tail); tail = XCDR (tail))
>     {
>       topmost_child = XFRAME (XCAR (tail));
>       copy_child_glyphs (root, topmost_child);
>     }
>
> What is the value of z_order?

Len, can you please print

  p root->visible

I have a suspicion that it might not be FRAME_VISIBLE_P. Alternatively,
you could configure with --enable-checking in which case we would see an
abort in combine_updates_for_frame.

The place in redisplay_internal where it is called is

      if (mini_frame != sf)
	{
	  XWINDOW (mini_window)->must_be_updated_p = true;
	  update_frame (mini_frame, false);
	  if (is_tty_frame (mini_frame))
	    combine_updates_for_frame (mini_frame, false);
	  mini_frame->cursor_type_changed = false;

There is no check for mini_frame being visible. At least not with a
quick look.