GNU bug report logs - #44180
28.0.50; Emacs frames won't redisplay unless resized

Previous Next

Full log

Message #71 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Tue, 27 Oct 2020 12:48:52 -0700

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  44180 <at> debbugs.gnu.org
>> Date: Tue, 27 Oct 2020 11:11:26 -0700
>> 
>> I think I'm going to need more help here, though. I have built master
>> with optimizations off, I start GDB in a controlling emacs, set a
>> breakpoint at xdisp.c:34381 at the beginning of expose_frame, and then
>> "run -Q".
>> 
>> That pops up a new frame, and we hit the breakpoint.
>
> That's the initial frame, isn't it?  If so, this is not the frame we
> want, we want a frame that was obscured and then gets the focus.
>
> To save yourself from a lot of unwanted breakpoint hits, I suggest
> this paradigm:
>
>  $ gdb ./emacs
>  (gdb) break Frecenter
>  (gdb) r -Q
>
> Inside Emacs:
>
>   M-x blink-cursor-mode RET
>   M-x global-eldoc-mode RET
>
> Now create one or more other frames and make them obscured
> ("iconified").  Now type C-l -- this will hit the breakpoint in
> Frecenter, and GDB will kick in.  Then set a breakpoint in
> expose_frame and type "continue".  Finally, switch to a frame that was
> obscured: does the breakpoint in expose_frame break, and if so, is
> Emacs told to expose the correct frame, the one that was obscured and
> is going to become visible?  If it's the correct frame, show the
> backtrace.
>
> Then do all this again, but after reverting the change which causes
> the problem.  By comparing the backtraces and the behavior, we might
> begin to understand how this change causes the problem in your case.

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.

Fingers crossed!

[master.txt (text/plain, attachment)]

[revert.txt (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.