bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Cc: 44180@debbugs.gnu.org
>> Date: Tue, 27 Oct 2020 12:48:52 -0700
>> 
>> Okay, hope this is helpful. I start in a workspace with only the
>> terminal, do the gdb dance, and when I run "r -Q" the first frame
>> appears, in stacked mode, taking up the whole screen. I create a second
>> frame: now i3 has a vertical stack of three windows: terminal, emacs1
>> and emacs2 -- emacs2 is focused.
>> 
>> I shut off blink cursor and global eldoc, note the frame addresses, then
>> move focus "wrap-around" style down and back around to the terminal, so
>> the emacs1 window (which is the "stuck" one in master) never receives
>> focus (that might not be important).
>> 
>> Back in the terminal I pause execution, set the expose_frame breakpoint,
>> turn on logging, and continue. Then move focus down to emacs1, back up
>> to the terminal, see the breakpoint has triggered, get a backtrace, and
>> confirm that the frame in question is indeed emacs1.
>> 
>> I did that exact routine in both master and a "revert" branch, with the
>> commit reverted.
>
> The backtraces look identical.  So does this mean expose_frame returns
> immediately in the "master" case without doing anything, but in the
> "revert" case it doesn't return?  If so, is the reason the fact that
> the problematic frame is marked as "garbaged" in the "master" case,
> but not in the "revert" case?

(I haven't had time to tackle this, and now will be away from the X11
machine for a week. Will report back in a couple weeks.)