bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm windowmanager seems to get lost after first use.

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 3 Oct 2022 08:37:06 +0200
> Cc: 58164@debbugs.gnu.org
> From: Jos de Kloe <kloe0040@planet.nl>
> 
> second time I hit C-z:
> 
> Thread 1 "emacs" hit Breakpoint 1, x_iconify_frame (f=0xe46c70) at 
> xterm.c:11976
> 11976   {
> (gdb) n
> 11982     if (FRAME_DISPLAY_INFO (f)->highlight_frame == f)
> (gdb) n
> 11983       FRAME_DISPLAY_INFO (f)->highlight_frame = 0;
> (gdb) n
> 11985     if (FRAME_ICONIFIED_P (f))
> (gdb) n
> Ffuncall (nargs=1, args=args@entry=0x7fffffffd258) at eval.c:3048
> 3048      lisp_eval_depth--;
> (gdb) n
> 3049      if (backtrace_debug_on_exit (specpdl + count))
> (gdb) n
> 3051      specpdl_ptr--;
> (gdb) n
> 3052      return val;
> (gdb) n
> 
> I hope this helps to zoom in on the problem.

It gives a hint.  Can you type "bt" before you type "n" here:

> 11985     if (FRAME_ICONIFIED_P (f))
> (gdb) n

and show the resulting backtrace?  Also, type "bt" _after_ you type
"n" there and see this line:

> Ffuncall (nargs=1, args=args@entry=0x7fffffffd258) at eval.c:3048
> 3048      lisp_eval_depth--;

You see, FRAME_ICONIFIED_P doesn't call Ffuncall, and there's no such
call anywhere in sight inside x_iconify_frame.  So either the macro
FRAME_ICONIFIED_P somehow signaled an error (which I don't think can
happen), or something else kicked us out of the function when we tried
to see if the frame is already iconified.  The question is: what did
kick us out and why?