bug#42655: 27.1; iconify-frame on a Lucid build may stuck the frame

[Eli Zaretskii]

> From: Bhavin Gandhi <bhavin7392@gmail.com>
> Date: Wed, 5 Aug 2020 00:23:09 +0530
> Cc: tino.calancha@gmail.com, 42655@debbugs.gnu.org, eggert@cs.ucla.edu, 
>       monnier@iro.umontreal.ca, uyennhi.qm@gmail.com
> 
> On Tue, 4 Aug 2020 at 22:11, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > And when you do create a new frame, do you see the redraw-display
> > command in the command history?  Also, what does "C-h l" show in that
> > other frame?
> 
> Yes, I can see the redraw-display command in command-history. This is
> what "C-h l" shows.
> 
> --8<---------------cut here---------------start------------->8---
>  C-z                    ;; suspend-frame
>  M-x                    ;; execute-extended-command
>  r                      ;; self-insert-command
>  e                      ;; self-insert-command
>  d                      ;; self-insert-command
>  r                      ;; self-insert-command
>  <return>               ;; minibuffer-complete-and-exit
>  C-x 5 2                ;; make-frame-command
>  ;; handle-switch-frame
>  C-h l                  ;; view-lossage
> --8<---------------cut here---------------end--------------->8---

So Emacs is nor stuck, it just doesn't redraw that frame for some
reason.

> > If you now attach a debugger to Emacs, what does the backtrace show?
> 
> Is running "gdb -i=mi -p PID" enough to generate this backtrace?

Yes.  Then type "thread apply all bt" once inside GDB.  But you only
need the -i=mi part if you invoke GDB from Emacs, via "M-x gdb RET".
If you invoke GDB from the shell prompt, it is better to omit -i=mi.

Thanks.