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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 58164 in the body.
You can then email your comments to 58164 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Jos de Kloe <kloe0040 <at> planet.nl>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.1; keybinding C-z to suspend-frame in fvwm windowmanager seems to
 get lost after first use.
Date: Thu, 29 Sep 2022 16:32:39 +0200

After migrating from emacs 27.2 to emacs 28-1 (default versions in 
Fedora 35 and Fedora 36) I observe a strange behavior for the C-z 
key-binding.
It only occurs if I use fvwm as windowmanager (which is still X11 
based), and is absent if I use xfce in stead.

For emacs 27-2 all works as intended and C-z will let the emacs window 
iconify. And double clicking the iconified emacs will raise it again. No 
problems here.

But for emacs 28-1 the C-z command works only once. If I raise emacs and 
try again to issue C-z it does not iconify, but looses focus in stead.
Also after regaining focus by moving the mouse out and back in to the 
emacs window, C-z does not return to its intended behavior.

I tested with the standard Fedora versions:
   emacs-1:27.2-9.fc35.x86_64
   emacs-1:28.1-2.fc36.x86_64
on a Fedora 36 workstation installation.

I also tested this by downloading the emacs sources for versions 27-2 
and 28-1 and compiling it myself, and the situation does not change. The 
bug is present in version 28-1 and absent in version 27.2.
So there is no relation to the Fedora packaging process. It really seems 
to be a bug inside emacs itself.




In GNU Emacs 28.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 
3.24.34, cairo version 1.17.6)
 of 2022-07-15 built on buildhw-x86-02.iad2.fedoraproject.org
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 36 (Workstation Edition)

Configured using:
 'configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xpm --with-x-toolkit=gtk3 --with-gpm=no
 --with-xwidgets --with-modules --with-harfbuzz --with-cairo --with-json
 --with-native-compilation build_alias=x86_64-redhat-linux-gnu
 host_alias=x86_64-redhat-linux-gnu CC=gcc 'CFLAGS=-DMAIL_USE_LOCKF -O2
 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
 -Wp,-D_GLIBCXX_ASSERTIONS
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
 -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
 LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Text

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads
xwidget-internal dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo move-toolbar gtk x-toolkit x multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 68513 5974)
 (symbols 48 6648 2)
 (strings 32 19711 2609)
 (string-bytes 1 675049)
 (vectors 16 14175)
 (vector-slots 8 300265 11315)
 (floats 8 22 33)
 (intervals 56 272 0)
 (buffers 992 12))

-- 
*******************************************************
  dr. J. de Kloe
  jos.de.kloe <at> knmi.nl  kloedej <at> knmi.nl
*******************************************************

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jos de Kloe <kloe0040 <at> planet.nl>
Cc: 58164 <at> debbugs.gnu.org
Subject: Re: bug#58164: 28.1;
 keybinding C-z to suspend-frame in fvwm windowmanager seems to get
 lost after first use.
Date: Thu, 29 Sep 2022 20:41:43 +0300

> Date: Thu, 29 Sep 2022 16:32:39 +0200
> From: Jos de Kloe <kloe0040 <at> planet.nl>
> 
> But for emacs 28-1 the C-z command works only once. If I raise emacs and 
> try again to issue C-z it does not iconify, but looses focus in stead.
> Also after regaining focus by moving the mouse out and back in to the 
> emacs window, C-z does not return to its intended behavior.

What does "C-h l" say after you press C-z and see the problematic
behavior?

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

From: Jos de Kloe <kloe0040 <at> planet.nl>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58164 <at> debbugs.gnu.org
Subject: Re: bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm
 windowmanager seems to get lost after first use.
Date: Fri, 30 Sep 2022 08:45:33 +0200

This is the output I get:

 <down> ;; next-line
 C-z	;; suspend-frame
 C-z	;; suspend-frame
 C-h l	;; view-lossage


On 9/29/22 19:41, Eli Zaretskii wrote:
>> Date: Thu, 29 Sep 2022 16:32:39 +0200
>> From: Jos de Kloe <kloe0040 <at> planet.nl>
>>
>> But for emacs 28-1 the C-z command works only once. If I raise emacs and
>> try again to issue C-z it does not iconify, but looses focus in stead.
>> Also after regaining focus by moving the mouse out and back in to the
>> emacs window, C-z does not return to its intended behavior.
> 
> What does "C-h l" say after you press C-z and see the problematic
> behavior?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jos de Kloe <kloe0040 <at> planet.nl>
Cc: 58164 <at> debbugs.gnu.org
Subject: Re: bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm
 windowmanager seems to get lost after first use.
Date: Fri, 30 Sep 2022 09:58:01 +0300

> Date: Fri, 30 Sep 2022 08:45:33 +0200
> Cc: 58164 <at> debbugs.gnu.org
> From: Jos de Kloe <kloe0040 <at> planet.nl>
> 
> This is the output I get:
> 
>   <down> ;; next-line
>   C-z	;; suspend-frame
>   C-z	;; suspend-frame
>   C-h l	;; view-lossage

So I guess the problem is in the X iconify_frame_hook, which is
x_iconify_frame.  If you can step through that function in a debugger
and see what's going on there, it might help.  Maybe Emacs thinks the
frame is already iconified, and thus does nothing?

Thanks.

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

From: Jos de Kloe <kloe0040 <at> planet.nl>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58164 <at> debbugs.gnu.org
Subject: Re: bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm
 windowmanager seems to get lost after first use.
Date: Mon, 3 Oct 2022 07:52:07 +0200

Yes I can run emacs in gdb, but I am not sure what to look at. Can you 
suggest which variables I should inspect?

On 9/30/22 08:58, Eli Zaretskii wrote:
>> Date: Fri, 30 Sep 2022 08:45:33 +0200
>> Cc: 58164 <at> debbugs.gnu.org
>> From: Jos de Kloe <kloe0040 <at> planet.nl>
>>
>> This is the output I get:
>>
>>    <down> ;; next-line
>>    C-z	;; suspend-frame
>>    C-z	;; suspend-frame
>>    C-h l	;; view-lossage
> 
> So I guess the problem is in the X iconify_frame_hook, which is
> x_iconify_frame.  If you can step through that function in a debugger
> and see what's going on there, it might help.  Maybe Emacs thinks the
> frame is already iconified, and thus does nothing?
> 
> Thanks.

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

From: Jos de Kloe <kloe0040 <at> planet.nl>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58164 <at> debbugs.gnu.org
Subject: Re: bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm
 windowmanager seems to get lost after first use.
Date: Mon, 3 Oct 2022 08:37:06 +0200

Just stepping through the instructions in this x_iconify_frame function 
I see the following happening:

first 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
11988     block_input ();
(gdb) n
11990     gui_set_bitmap_icon (f);
(gdb) n
11993     if (FRAME_GTK_OUTER_WIDGET (f))
(gdb) n
11995         if (! FRAME_VISIBLE_P (f))
(gdb) n
11998         gtk_window_iconify (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)));
(gdb) n
11999         SET_FRAME_VISIBLE (f, 0);
(gdb) n
12000         SET_FRAME_ICONIFIED (f, true);
(gdb) n
12001         unblock_input ();
(gdb) n
12002         return;

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 <at> 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.

On 9/30/22 08:58, Eli Zaretskii wrote:
>> Date: Fri, 30 Sep 2022 08:45:33 +0200
>> Cc: 58164 <at> debbugs.gnu.org
>> From: Jos de Kloe <kloe0040 <at> planet.nl>
>>
>> This is the output I get:
>>
>>    <down> ;; next-line
>>    C-z	;; suspend-frame
>>    C-z	;; suspend-frame
>>    C-h l	;; view-lossage
> 
> So I guess the problem is in the X iconify_frame_hook, which is
> x_iconify_frame.  If you can step through that function in a debugger
> and see what's going on there, it might help.  Maybe Emacs thinks the
> frame is already iconified, and thus does nothing?
> 
> Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jos de Kloe <kloe0040 <at> planet.nl>
Cc: 58164 <at> debbugs.gnu.org
Subject: Re: bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm
 windowmanager seems to get lost after first use.
Date: Mon, 03 Oct 2022 19:47:18 +0300

> Date: Mon, 3 Oct 2022 08:37:06 +0200
> Cc: 58164 <at> debbugs.gnu.org
> From: Jos de Kloe <kloe0040 <at> 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 <at> 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 <at> 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?

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

From: Jos de Kloe <kloe0040 <at> planet.nl>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58164 <at> debbugs.gnu.org
Subject: Re: bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm
 windowmanager seems to get lost after first use.
Date: Mon, 3 Oct 2022 19:39:20 +0200

On 10/3/22 18:47, Eli Zaretskii wrote:
>> Date: Mon, 3 Oct 2022 08:37:06 +0200
>> Cc: 58164 <at> debbugs.gnu.org
>> From: Jos de Kloe <kloe0040 <at> 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 <at> 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:

before:

Thread 1 "emacs" hit Breakpoint 1, x_iconify_frame (f=0xe293e0) 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) bt
#0  x_iconify_frame (f=0xe293e0) at xterm.c:11983
#1  0x0000000000428191 in Ficonify_frame (frame=0x0) at frame.c:2811
#2  0x00000000005683b2 in funcall_subr
    (subr=0x989340 <Siconify_frame>, numargs=numargs <at> entry=0, 
args=args <at> entry=0x7fffffffd260) at eval.c:3098
#3  0x0000000000566d80 in Ffuncall (nargs=1, args=args <at> entry=0x7fffffffd258)
    at eval.c:3023
#4  0x000000000059a50a in exec_byte_code
    (bytestr=0x7ffff1aea90c, vector=<optimized out>, 
maxdepth=<optimized out>, args_template=args_template <at> entry=0x2, 
nargs=nargs <at> entry=0, args=<optimized out>,
    args <at> entry=0x7fffffffd400) at bytecode.c:632
#5  0x0000000000569541 in fetch_and_exec_byte_code
    (args=0x7fffffffd400, nargs=0, syms_left=0x2, fun=0x7ffff1aea8a5)
    at /home/jos/temp_emacs/emacs-28.1/src/lisp.h:1853
#6  funcall_lambda
    (fun=0x7ffff1aea8a5, nargs=nargs <at> entry=0, 
arg_vector=arg_vector <at> entry=0x7fffffffd400)
    at eval.c:3228
#7  0x0000000000566d69 in Ffuncall (nargs=1, args=args <at> entry=0x7fffffffd3f8)
    at eval.c:3027
#8  0x000000000059a50a in exec_byte_code
    (bytestr=0x7ffff1aea94c, vector=<optimized out>, 
maxdepth=<optimized out>, args_template=args_template <at> entry=0x2, 
nargs=nargs <at> entry=0, args=<optimized out>,
    args <at> entry=0x7fffffffd7b0) at bytecode.c:632
#9  0x0000000000569541 in fetch_and_exec_byte_code
    (args=0x7fffffffd7b0, nargs=0, syms_left=0x2, fun=0x7ffff1aea7a5)
    at /home/jos/temp_emacs/emacs-28.1/src/lisp.h:1853
#10 funcall_lambda
    (fun=0x7ffff1aea7a5, nargs=nargs <at> entry=0, 
arg_vector=arg_vector <at> entry=0x7fffffffd7b0)
    at eval.c:3228
#11 0x0000000000566d69 in Ffuncall (nargs=nargs <at> entry=1, 
args=args <at> entry=0x7fffffffd7a8)
    at eval.c:3027
#12 0x0000000000563b8f in Ffuncall_interactively (nargs=1, 
args=0x7fffffffd7a8)
#13 0x0000000000568388 in funcall_subr
    (subr=0x996740 <Sfuncall_interactively>, numargs=numargs <at> entry=1, 
args=args <at> entry=0x7fffffffd7a8) at eval.c:3078
#14 0x0000000000566d80 in Ffuncall (nargs=nargs <at> entry=2, 
args=args <at> entry=0x7fffffffd7a0)
    at eval.c:3023
#15 0x0000000000567098 in Fapply (nargs=nargs <at> entry=3, 
args=args <at> entry=0x7fffffffd7a0)
    at eval.c:2606
#16 0x00000000005640fa in Fcall_interactively
    (function=0x7ffff10e1250, record_flag=0x0, keys=0x7ffff1e7eae5) at 
callint.c:353
#17 0x00000000005683d8 in funcall_subr
    (subr=0x996700 <Scall_interactively>, numargs=numargs <at> entry=3, 
args=args <at> entry=0x7fffffffd900) at eval.c:3103
#18 0x0000000000566d80 in Ffuncall (nargs=4, args=args <at> entry=0x7fffffffd8f8)
    at eval.c:3023
#19 0x000000000059a50a in exec_byte_code
    (bytestr=0x7ffff186486c, vector=<optimized out>, 
maxdepth=<optimized out>, args_template=args_template <at> entry=0x1006, 
nargs=nargs <at> entry=1, args=<optimized out>,
    args <at> entry=0x7fffffffdb48) at bytecode.c:632
#20 0x0000000000569541 in fetch_and_exec_byte_code
    (args=0x7fffffffdb48, nargs=1, syms_left=0x1006, fun=0x7ffff18644a5)
    at /home/jos/temp_emacs/emacs-28.1/src/lisp.h:1853
#21 funcall_lambda
    (fun=0x7ffff18644a5, nargs=nargs <at> entry=1, 
arg_vector=arg_vector <at> entry=0x7fffffffdb48)
    at eval.c:3228
#22 0x0000000000566d69 in Ffuncall (nargs=nargs <at> entry=2, 
args=args <at> entry=0x7fffffffdb40)
    at eval.c:3027
#23 0x0000000000566f19 in call1 (fn=fn <at> entry=0x4590, arg1=<optimized 
out>) at eval.c:2883
#24 0x0000000000502a36 in command_loop_1 () at keyboard.c:1505
#25 0x000000000056612d in internal_condition_case
    (bfun=bfun <at> entry=0x5023eb <command_loop_1>, 
handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x4f7da1 <cmd_error>) at 
eval.c:1450
#26 0x00000000004f4841 in command_loop_2 (handlers=handlers <at> entry=0x90)
    at keyboard.c:1133
#27 0x00000000005660a4 in internal_catch
    (tag=tag <at> entry=0xe850, func=func <at> entry=0x4f482b <command_loop_2>, 
arg=arg <at> entry=0x90)
    at eval.c:1181
#28 0x00000000004f480d in command_loop () at keyboard.c:1111
#29 0x00000000004f7a2e in recursive_edit_1 () at keyboard.c:720
#30 0x00000000004f7cf9 in Frecursive_edit () at keyboard.c:803
#31 0x00000000004f3d72 in main (argc=3, argv=0x7fffffffdfd8) at emacs.c:2354


and after:

(gdb) n
11985     if (FRAME_ICONIFIED_P (f))
(gdb) bt
#0  x_iconify_frame (f=0xe293e0) at xterm.c:11985
#1  0x0000000000428191 in Ficonify_frame (frame=0x0) at frame.c:2811
#2  0x00000000005683b2 in funcall_subr
    (subr=0x989340 <Siconify_frame>, numargs=numargs <at> entry=0, 
args=args <at> entry=0x7fffffffd260) at eval.c:3098
#3  0x0000000000566d80 in Ffuncall (nargs=1, args=args <at> entry=0x7fffffffd258)
    at eval.c:3023
#4  0x000000000059a50a in exec_byte_code
    (bytestr=0x7ffff1aea90c, vector=<optimized out>, 
maxdepth=<optimized out>, args_template=args_template <at> entry=0x2, 
nargs=nargs <at> entry=0, args=<optimized out>,
    args <at> entry=0x7fffffffd400) at bytecode.c:632
#5  0x0000000000569541 in fetch_and_exec_byte_code
    (args=0x7fffffffd400, nargs=0, syms_left=0x2, fun=0x7ffff1aea8a5)
    at /home/jos/temp_emacs/emacs-28.1/src/lisp.h:1853
#6  funcall_lambda
    (fun=0x7ffff1aea8a5, nargs=nargs <at> entry=0, 
arg_vector=arg_vector <at> entry=0x7fffffffd400)
    at eval.c:3228
#7  0x0000000000566d69 in Ffuncall (nargs=1, args=args <at> entry=0x7fffffffd3f8)
    at eval.c:3027
#8  0x000000000059a50a in exec_byte_code
    (bytestr=0x7ffff1aea94c, vector=<optimized out>, 
maxdepth=<optimized out>, args_template=args_template <at> entry=0x2, 
nargs=nargs <at> entry=0, args=<optimized out>,
    args <at> entry=0x7fffffffd7b0) at bytecode.c:632
#9  0x0000000000569541 in fetch_and_exec_byte_code
    (args=0x7fffffffd7b0, nargs=0, syms_left=0x2, fun=0x7ffff1aea7a5)
    at /home/jos/temp_emacs/emacs-28.1/src/lisp.h:1853
#10 funcall_lambda
    (fun=0x7ffff1aea7a5, nargs=nargs <at> entry=0, 
arg_vector=arg_vector <at> entry=0x7fffffffd7b0)
    at eval.c:3228
#11 0x0000000000566d69 in Ffuncall (nargs=nargs <at> entry=1, 
args=args <at> entry=0x7fffffffd7a8)
    at eval.c:3027
#12 0x0000000000563b8f in Ffuncall_interactively (nargs=1, 
args=0x7fffffffd7a8)
    at callint.c:260
#13 0x0000000000568388 in funcall_subr
    (subr=0x996740 <Sfuncall_interactively>, numargs=numargs <at> entry=1, 
args=args <at> entry=0x7fffffffd7a8) at eval.c:3078
#14 0x0000000000566d80 in Ffuncall (nargs=nargs <at> entry=2, 
args=args <at> entry=0x7fffffffd7a0)
    at eval.c:3023
#15 0x0000000000567098 in Fapply (nargs=nargs <at> entry=3, 
args=args <at> entry=0x7fffffffd7a0)
    at eval.c:2606
#16 0x00000000005640fa in Fcall_interactively
    (function=0x7ffff10e1250, record_flag=0x0, keys=0x7ffff1e7eae5) at 
callint.c:353
#17 0x00000000005683d8 in funcall_subr
    (subr=0x996700 <Scall_interactively>, numargs=numargs <at> entry=3, 
args=args <at> entry=0x7fffffffd900) at eval.c:3103
#18 0x0000000000566d80 in Ffuncall (nargs=4, args=args <at> entry=0x7fffffffd8f8)
    at eval.c:3023
#19 0x000000000059a50a in exec_byte_code
    (bytestr=0x7ffff186486c, vector=<optimized out>, 
maxdepth=<optimized out>, args_template=args_template <at> entry=0x1006, 
nargs=nargs <at> entry=1, args=<optimized out>,
    args <at> entry=0x7fffffffdb48) at bytecode.c:632
#20 0x0000000000569541 in fetch_and_exec_byte_code
    (args=0x7fffffffdb48, nargs=1, syms_left=0x1006, fun=0x7ffff18644a5)
    at /home/jos/temp_emacs/emacs-28.1/src/lisp.h:1853
#21 funcall_lambda
    (fun=0x7ffff18644a5, nargs=nargs <at> entry=1, 
arg_vector=arg_vector <at> entry=0x7fffffffdb48)
    at eval.c:3228
#22 0x0000000000566d69 in Ffuncall (nargs=nargs <at> entry=2, 
args=args <at> entry=0x7fffffffdb40)
    at eval.c:3027
#23 0x0000000000566f19 in call1 (fn=fn <at> entry=0x4590, arg1=<optimized 
out>) at eval.c:2883
#24 0x0000000000502a36 in command_loop_1 () at keyboard.c:1505
#25 0x000000000056612d in internal_condition_case
    (bfun=bfun <at> entry=0x5023eb <command_loop_1>, 
handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x4f7da1 <cmd_error>) at 
eval.c:1450
#26 0x00000000004f4841 in command_loop_2 (handlers=handlers <at> entry=0x90)
    at keyboard.c:1133
#27 0x00000000005660a4 in internal_catch
    (tag=tag <at> entry=0xe850, func=func <at> entry=0x4f482b <command_loop_2>, 
arg=arg <at> entry=0x90)
    at eval.c:1181
#28 0x00000000004f480d in command_loop () at keyboard.c:1111
#29 0x00000000004f7a2e in recursive_edit_1 () at keyboard.c:720
#30 0x00000000004f7cf9 in Frecursive_edit () at keyboard.c:803
#31 0x00000000004f3d72 in main (argc=3, argv=0x7fffffffdfd8) at emacs.c:2354



>> Ffuncall (nargs=1, args=args <at> 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?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jos de Kloe <kloe0040 <at> planet.nl>
Cc: 58164 <at> debbugs.gnu.org
Subject: Re: bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm
 windowmanager seems to get lost after first use.
Date: Mon, 03 Oct 2022 20:56:44 +0300

> Date: Mon, 3 Oct 2022 19:39:20 +0200
> Cc: 58164 <at> debbugs.gnu.org
> From: Jos de Kloe <kloe0040 <at> planet.nl>
> 
> and after:
> 
> (gdb) n
> 11985     if (FRAME_ICONIFIED_P (f))
> (gdb) bt

Thanks, but I meant "after" here:

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

That is, after you step over the "if (FRAME_ICONIFIED_P (f))" line and
end up in Ffuncall.

But I think I see the reason: indeed Emacs thinks that the frame is
still iconified, so it does nothing and returns.

So I guess some X event that was supposed to arrive and tell us that
the frame is no longer iconified didn't arrive or something?  I hope
Po Lu will be able to look into this soon.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Jos de Kloe <kloe0040 <at> planet.nl>, 58164 <at> debbugs.gnu.org
Subject: Re: bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm
 windowmanager seems to get lost after first use.
Date: Tue, 04 Oct 2022 08:37:22 +0800

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

>> Date: Mon, 3 Oct 2022 19:39:20 +0200
>> Cc: 58164 <at> debbugs.gnu.org
>> From: Jos de Kloe <kloe0040 <at> planet.nl>
>> 
>> and after:
>> 
>> (gdb) n
>> 11985     if (FRAME_ICONIFIED_P (f))
>> (gdb) bt
>
> Thanks, but I meant "after" here:
>
>> Ffuncall (nargs=1, args=args <at> entry=0x7fffffffd258) at eval.c:3048
>> 3048      lisp_eval_depth--;
>
> That is, after you step over the "if (FRAME_ICONIFIED_P (f))" line and
> end up in Ffuncall.
>
> But I think I see the reason: indeed Emacs thinks that the frame is
> still iconified, so it does nothing and returns.
>
> So I guess some X event that was supposed to arrive and tell us that
> the frame is no longer iconified didn't arrive or something?  I hope
> Po Lu will be able to look into this soon.

Thanks, I will look into this bug.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Jos de Kloe <kloe0040 <at> planet.nl>, 58164 <at> debbugs.gnu.org
Subject: Re: bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm
 windowmanager seems to get lost after first use.
Date: Tue, 04 Oct 2022 09:25:45 +0800

Po Lu <luangruo <at> yahoo.com> writes:

> Thanks, I will look into this bug.

Should be fixed now on the master branch.  Jos, could you please see if
the problem has been resolved for you as well?

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

From: Jos de Kloe <kloe0040 <at> planet.nl>
To: Po Lu <luangruo <at> yahoo.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 58164 <at> debbugs.gnu.org
Subject: Re: bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm
 windowmanager seems to get lost after first use.
Date: Tue, 4 Oct 2022 08:45:17 +0200

Yes, I can confirm that the master branch solves the issue on my side. 
Iconify works again as intended, also after several iconify/de-iconify 
actions.

Thanks a lot for your support !


On 10/4/22 03:25, Po Lu wrote:
> Po Lu <luangruo <at> yahoo.com> writes:
> 
>> Thanks, I will look into this bug.
> 
> Should be fixed now on the master branch.  Jos, could you please see if
> the problem has been resolved for you as well?

Message #45 received at 58164-done <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Jos de Kloe <kloe0040 <at> planet.nl>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58164-done <at> debbugs.gnu.org
Subject: Re: bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm
 windowmanager seems to get lost after first use.
Date: Tue, 04 Oct 2022 16:30:49 +0800

Jos de Kloe <kloe0040 <at> planet.nl> writes:

> Yes, I can confirm that the master branch solves the issue on my
> side. Iconify works again as intended, also after several
> iconify/de-iconify actions.
>
> Thanks a lot for your support !

Thanks, closing.

Previous Next

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