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

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

[Tino Calancha]

X-Debbugs-Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Paul Eggert <eggert@cs.ucla.edu>, <uyennhi.qm@gmail.com>
Severity: wishlist

* To reproduce

-------------------------------------------------------------------------------
In a GUI session, with Emacs built with Lucid toolkit in a Linux machine,
do:
emacs -Q
C-z
;; select again the window displaying the Emacs GUI
-------------------------------------------------------------------------------

- You cannot insert characters in the *scratch* buffer.
- Normal movement, for intance, `C-n' or `C-f' doesn't work.

trick: `M-x' recovers the frame.

Unfortunately, when I start Emacs without the `-Q' flag, then this trick
doesn't work for me: the frame keeps unresponsive forever, and I have 2 choices:
1) Restart Emacs session (unaceptable for users).
2) Get 'blindly' (ie, without echo area feedback) a new frame:
C-x 5 b foo RET


* Expected behavior:

After `C-z' and select again the Emacs GUI you have a fully responsive
frame displaying the *scratch* buffer: you can insert characters and/or
move the cursor anywhere.


* Workaround:
Install gtk3-devel and build Emacs with GTK3 toolkit


In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2020-08-01 built on calancha-pc.dy.bbexcite.jp
Repository revision: f54ddb0198640e38c1d34bf6031ff5117c117c85
Repository branch: emacs-27
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux 10 (buster)

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit [2 times]
funcall-interactively: End of buffer
scroll-up-command: End of buffer
Configured using:
 'configure --with-x-toolkit=lucid'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS
LIBSYSTEMD PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-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
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs 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
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
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 elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
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 charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 44708 6402)
 (symbols 48 5984 1)
 (strings 32 16489 1646)
 (string-bytes 1 525028)
 (vectors 16 9267)
 (vector-slots 8 124678 11056)
 (floats 8 22 43)
 (intervals 56 212 0)
 (buffers 1000 11))

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

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Date: Sat, 01 Aug 2020 20:46:03 +0200
> Cc: paul eggert <eggert@cs.ucla.edu>, stefan monnier <monnier@iro.umontreal.ca>,
>  uyennhi.qm@gmail.com
> 
> In a GUI session, with Emacs built with Lucid toolkit in a Linux machine,
> do:
> emacs -Q
> C-z
> ;; select again the window displaying the Emacs GUI
> -------------------------------------------------------------------------------
> 
> - You cannot insert characters in the *scratch* buffer.
> - Normal movement, for intance, `C-n' or `C-f' doesn't work.

If you now attach a debugger to Emacs, what does the backtrace show?

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

[Tino Calancha]

Tino Calancha <tino.calancha@gmail.com> writes:

> -------------------------------------------------------------------------------
> In a GUI session, with Emacs built with Lucid toolkit in a Linux machine,
> do:
> emacs -Q
> C-z
> ;; select again the window displaying the Emacs GUI
> -------------------------------------------------------------------------------
>
> - You cannot insert characters in the *scratch* buffer.
> - Normal movement, for intance, `C-n' or `C-f' doesn't work.

It is a regression from Emacs 26.? with the following commit:

commit dee8674414fae2323fd9cbf05aa762e72fa575e5
Author: Stefan Monnier <monnier@iro.umontreal.ca>
Date:   Thu Feb 23 21:17:04 2017 -0500

    Minor redisplay optimisations
    
    * src/frame.c (Ficonify_frame): No need to redisplay everything.

The following patch fixed it:

--8<-----------------------------cut here---------------start------------->8---
commit 96e56d237d27d0873914319812a576969f60486f
Author: Tino Calancha <ccalancha@suse.com>
Date:   Sun Aug 2 14:45:56 2020 +0200

    Notify when a frame is iconified in Lucid builds
    
    If Emacs is built without x toolkit or built with Lucid,
    then we have to notify when a frame is iconified (Bug#42655).
    - src/frame (iconify-frame):
    Set windows_or_buffers_changed to a non-zero value.

diff --git a/src/frame.c b/src/frame.c
index 4dd8bb1804..640aa5c4e3 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -2738,6 +2738,11 @@ DEFUN ("iconify-frame", Ficonify_frame, Siconify_frame,
   if (FRAME_WINDOW_P (f) && FRAME_TERMINAL (f)->iconify_frame_hook)
     FRAME_TERMINAL (f)->iconify_frame_hook (f);
 
+#if (!defined USE_X_TOOLKIT || defined USE_LUCID) /* (Bug#42655) */
+  /* Make menu bar update for the Buffers and Frames menus. */
+  windows_or_buffers_changed = 17;
+#endif
+
   return Qnil;
 }
 
--8<-----------------------------cut here---------------end--------------->8---

In GNU Emacs 27.1 (build 17, x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars)
 of 2020-08-02 built on localhost.example.com
Repository revision: f54ddb0198640e38c1d34bf6031ff5117c117c85
Repository branch: emacs-27
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: openSUSE Tumbleweed

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

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Date: Sun, 02 Aug 2020 15:07:32 +0200
> Cc: paul eggert <eggert@cs.ucla.edu>, stefan monnier <monnier@iro.umontreal.ca>,
>  uyennhi.qm@gmail.com
> 
> Tino Calancha <tino.calancha@gmail.com> writes:
> 
> > emacs -Q
> > C-z
> > ;; select again the window displaying the Emacs GUI
> > -------------------------------------------------------------------------------
> >
> > - You cannot insert characters in the *scratch* buffer.
> > - Normal movement, for intance, `C-n' or `C-f' doesn't work.
> 
> It is a regression from Emacs 26.? with the following commit:
> 
> commit dee8674414fae2323fd9cbf05aa762e72fa575e5
> Author: Stefan Monnier <monnier@iro.umontreal.ca>
> Date:   Thu Feb 23 21:17:04 2017 -0500
> 
>     Minor redisplay optimisations
>     
>     * src/frame.c (Ficonify_frame): No need to redisplay everything.
> 
> The following patch fixed it:
> 
> --8<-----------------------------cut here---------------start------------->8---
> commit 96e56d237d27d0873914319812a576969f60486f
> Author: Tino Calancha <ccalancha@suse.com>
> Date:   Sun Aug 2 14:45:56 2020 +0200
> 
>     Notify when a frame is iconified in Lucid builds
>     
>     If Emacs is built without x toolkit or built with Lucid,
>     then we have to notify when a frame is iconified (Bug#42655).
>     - src/frame (iconify-frame):
>     Set windows_or_buffers_changed to a non-zero value.
> 
> diff --git a/src/frame.c b/src/frame.c
> index 4dd8bb1804..640aa5c4e3 100644
> --- a/src/frame.c
> +++ b/src/frame.c
> @@ -2738,6 +2738,11 @@ DEFUN ("iconify-frame", Ficonify_frame, Siconify_frame,
>    if (FRAME_WINDOW_P (f) && FRAME_TERMINAL (f)->iconify_frame_hook)
>      FRAME_TERMINAL (f)->iconify_frame_hook (f);
>  
> +#if (!defined USE_X_TOOLKIT || defined USE_LUCID) /* (Bug#42655) */
> +  /* Make menu bar update for the Buffers and Frames menus. */
> +  windows_or_buffers_changed = 17;
> +#endif

Thanks, but I'm afraid this is not necessarily TRT.  You simply revert
part of Stefan's change for some configurations, but I don't
understand why not setting windows_or_buffers_changed affects Lucid,
but not GTK.  Did you succeed in understanding the reason?

And btw, why do you also add this for non-toolkit builds: did you see
the same problem in that configuration?

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

[Tino Calancha]

> Thanks, but I'm afraid this is not necessarily TRT.  You simply revert
> part of Stefan's change for some configurations, but I don't
> understand why not setting windows_or_buffers_changed affects Lucid,
> but not GTK.  Did you succeed in understanding the reason?

I don't know the reason.  For some reason, Stefan optimisation 
affects Lucid; probably he did not test his patch for that 
configuration.

If someone wants to dig deeper, it is very welcome; if nobody can, 
please, consider applying this simple patch.
I have been suffering this bug for months; until I realized I was able to
workaround getting a new frame, I was just closing the Emacs session
with dozens of visited buffers :-|

> And btw, why do you also add this for non-toolkit builds: did you see
> the same problem in that configuration?
I have reproduced the bug with both flags
  --with-x-toolkit=no
and 
--with-x-toolkit=lucid

I am just trying to cover in the patch all scenario where I have 
reproduced the bug; I can not test other configurations.
How about in Windows? Have you seen this bug?

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

[Stefan Monnier]

FWIW, it would be worthwhile to investigate the origin/cause of the
problem, but as a stopgap his patch looks fine to me (I'd add a FIXME
in the comment, indicating that this is just a workaround rather than
a real fix).


        Stefan

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

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Date: Mon, 3 Aug 2020 21:46:49 +0200 (CEST)
> cc: Tino Calancha <tino.calancha@gmail.com>, 42655@debbugs.gnu.org, 
>     eggert@cs.ucla.edu, monnier@iro.umontreal.ca, uyennhi.qm@gmail.com
> 
> How about in Windows? Have you seen this bug?

No, nothing like that.

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

[Eli Zaretskii]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

In any case, I asked for a C-level backtrace when I responded to your original report.  Can you please attach a debugger to Emacs after selecting the previously iconified frame, and show such a backtrace?  Please do that with an unpatched Emacs and in "emacs -Q".

Thanks.


On August 4, 2020 5:21:21 AM GMT+03:00, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Tino Calancha <tino.calancha@gmail.com>
>> Date: Mon, 3 Aug 2020 21:46:49 +0200 (CEST)
>> cc: Tino Calancha <tino.calancha@gmail.com>, 42655@debbugs.gnu.org, 
>>     eggert@cs.ucla.edu, monnier@iro.umontreal.ca,
>uyennhi.qm@gmail.com
>> 
>> How about in Windows? Have you seen this bug?
>
>No, nothing like that.

-- 
נשלח ממכשיר האנדרואיד שלי בעזרת אפליקציית הדואר K-9. סלח לי על הקצרנות.

[-- Attachment #2: Type: text/html, Size: 1232 bytes --]

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

[Eli Zaretskii]

> Date: Tue, 04 Aug 2020 06:59:59 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, uyennhi.qm@gmail.com
> 
> In any case, I asked for a C-level backtrace when I responded to your original report. Can you please attach
> a debugger to Emacs after selecting the previously iconified frame, and show such a backtrace? Please do
> that with an unpatched Emacs and in "emacs -Q".

Also, I don't understand what you mean in your original report by
"unresponsive frame" and "cannot insert characters".  Do you mean that
Emacs is "stuck" and doesn't respond, or do you mean that the results
of whatever you do are not displayed?  And what _do_ you see displayed
when you "select the window displaying the Emacs GUI" after C-z?

If the problem is with display, then does it help to type (blindly)
"M-x redraw-display RET"?

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

[Bhavin Gandhi]

I was able to reproduce this with Lucid. I will try to read about
attaching debugger and post the results here.

On Tue, 4 Aug 2020 at 19:59, Eli Zaretskii <eliz@gnu.org> wrote:
> Also, I don't understand what you mean in your original report by
> "unresponsive frame" and "cannot insert characters".  Do you mean that
> Emacs is "stuck" and doesn't respond, or do you mean that the results
> of whatever you do are not displayed?

The latter. The frame gets frozen, whatever we do is not displayed.  The
menu bar is functional though.

> And what _do_ you see displayed when you "select the window displaying
> the Emacs GUI" after C-z?

It's just shown as frozen in a state before we press C-z. I ran M-x zone
and then pressed C-z, the frame was frozen with 'Zoning...sorry' in the
minibuffer.

> If the problem is with display, then does it help to type (blindly)
> "M-x redraw-display RET"?

No it doesn't. The only thing worked was to create a new frame.

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

[Eli Zaretskii]

> From: Bhavin Gandhi <bhavin7392@gmail.com>
> Date: Tue, 4 Aug 2020 20:44:35 +0530
> Cc: tino.calancha@gmail.com, 42655@debbugs.gnu.org, eggert@cs.ucla.edu, 
> 	monnier@iro.umontreal.ca, uyennhi.qm@gmail.com
> 
> > If the problem is with display, then does it help to type (blindly)
> > "M-x redraw-display RET"?
> 
> No it doesn't.

Fascinating.

> The only thing worked was to create a new frame.

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?

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

[Bhavin Gandhi]

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

> 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?

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.

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

[Bhavin Gandhi]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

On Wed, 5 Aug 2020 at 00:37, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > > 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 for the suggestion, here is the backtrace at the point when Emacs
is stuck. Adding it as an attachment.

[-- Attachment #2: bug-42655-backtrace --]
[-- Type: application/octet-stream, Size: 6780 bytes --]

$ gdb -p 887349
GNU gdb (GDB) Fedora 9.1-5.fc32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 887349
[New LWP 887355]
[New LWP 887356]
[New LWP 887357]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007efde644b1a6 in pselect () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install Xaw3d-1.6.3-2.fc32.x86_64 alsa-lib-1.2.3.2-1.fc32.x86_64 bzip2-libs-1.0.8-2.fc32.x86_64 cairo-1.16.0-8.fc32.x86_64 cairo-gobject-1.16.0-8.fc32.x86_64 dbus-libs-1.12.20-1.fc32.x86_64 dconf-0.36.0-1.fc32.x86_64 fontconfig-2.13.92-9.fc32.x86_64 freetype-2.10.1-2.fc32.x86_64 fribidi-1.0.9-1.fc32.x86_64 gdk-pixbuf2-2.40.0-2.fc32.x86_64 giflib-5.2.1-4.fc32.x86_64 glib2-2.64.3-2.fc32.x86_64 glibc-2.31-2.fc32.x86_64 gmp-6.1.2-13.fc32.x86_64 gnutls-3.6.14-2.fc32.x86_64 graphite2-1.3.14-1.fc32.x86_64 harfbuzz-2.6.4-3.fc32.x86_64 jansson-2.12-5.fc32.x86_64 jbigkit-libs-2.1-18.fc32.x86_64 libICE-1.0.10-3.fc32.x86_64 libSM-1.2.3-5.fc32.x86_64 libX11-1.6.9-3.fc32.x86_64 libX11-xcb-1.6.9-3.fc32.x86_64 libXau-1.0.9-3.fc32.x86_64 libXext-1.3.4-3.fc32.x86_64 libXfixes-5.0.3-11.fc32.x86_64 libXinerama-1.1.4-5.fc32.x86_64 libXmu-1.1.3-3.fc32.x86_64 libXpm-3.5.13-2.fc32.x86_64 libXrender-0.9.10-11.fc32.x86_64 libXt-1.2.0-1.fc32.x86_64 libacl-2.2.53-5.fc32.x86_64 libattr-2.4.48-8.fc32.x86_64 libdatrie-0.2.9-11.fc32.x86_64 libffi-3.1-24.fc32.x86_64 libgcrypt-1.8.5-3.fc32.x86_64 libidn2-2.3.0-2.fc32.x86_64 libjpeg-turbo-2.0.4-3.fc32.x86_64 libotf-0.9.13-15.fc32.x86_64 libpng-1.6.37-3.fc32.x86_64 librsvg2-2.48.7-1.fc32.x86_64 libselinux-3.0-3.fc32.x86_64 libtiff-4.1.0-2.fc32.x86_64 libuuid-2.35.2-1.fc32.x86_64 libxcb-1.13.1-4.fc32.x86_64 libxml2-2.9.10-3.fc32.x86_64 ncurses-libs-6.1-15.20191109.fc32.x86_64 nettle-3.5.1-5.fc32.x86_64 p11-kit-0.23.20-1.fc32.x86_64 pango-1.44.7-2.fc32.x86_64 systemd-libs-245.7-1.fc32.x86_64 zlib-1.2.11-21.fc32.x86_64
(gdb) set pagination off
set pagination off
(gdb) thread apply all bt
thread apply all bt

Thread 4 (Thread 0x7efde35a1700 (LWP 887357)):
#0  0x00007efde6448b6f in poll () at /lib64/libc.so.6
#1  0x00007efde6eb2ace in g_main_context_iterate.constprop () at /lib64/libglib-2.0.so.0
#2  0x00007efde6eb2e53 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x00007efde71316aa in gdbus_shared_thread_func () at /lib64/libgio-2.0.so.0
#4  0x00007efde6edc812 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007efde6692432 in start_thread () at /lib64/libpthread.so.0
#6  0x00007efde64539d3 in clone () at /lib64/libc.so.6

Thread 3 (Thread 0x7efde3f32700 (LWP 887356)):
#0  0x00007efde6448b6f in poll () at /lib64/libc.so.6
#1  0x00007efde6eb2ace in g_main_context_iterate.constprop () at /lib64/libglib-2.0.so.0
#2  0x00007efde6eb2c03 in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007efde3f44fbd in dconf_gdbus_worker_thread () at /usr/lib64/gio/modules/libdconfsettings.so
#4  0x00007efde6edc812 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007efde6692432 in start_thread () at /lib64/libpthread.so.0
#6  0x00007efde64539d3 in clone () at /lib64/libc.so.6

Thread 2 (Thread 0x7efde48e9700 (LWP 887355)):
#0  0x00007efde6448b6f in poll () at /lib64/libc.so.6
#1  0x00007efde6eb2ace in g_main_context_iterate.constprop () at /lib64/libglib-2.0.so.0
#2  0x00007efde6eb2c03 in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007efde6eb2c51 in glib_worker_main () at /lib64/libglib-2.0.so.0
#4  0x00007efde6edc812 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007efde6692432 in start_thread () at /lib64/libpthread.so.0
#6  0x00007efde64539d3 in clone () at /lib64/libc.so.6

Thread 1 (Thread 0x7efde5a3e080 (LWP 887349)):
#0  0x00007efde644b1a6 in pselect () at /lib64/libc.so.6
#1  0x00000000008b7277 in really_call_select (arg=0x7ffc18d6b460) at ../../src/thread.c:586
#2  0x000000000073c366 in flush_stack_call_func (func=0x8b71dd <really_call_select>, arg=0x7ffc18d6b460) at ../../src/alloc.c:4951
#3  0x00000000008b732d in thread_select (func=0x4161f0 <pselect@plt>, max_fds=7, rfds=0x7ffc18d6b990, wfds=0x7ffc18d6b910, efds=0x0, timeout=0x7ffc18d6bc70, sigmask=0x0) at ../../src/thread.c:616
#4  0x000000000091323b in xg_select (fds_lim=7, rfds=0x7ffc18d6bd10, wfds=0x7ffc18d6bc90, efds=0x0, timeout=0x7ffc18d6bc70, sigmask=0x0) at ../../src/xgselect.c:117
#5  0x0000000000832699 in wait_reading_process_output (time_limit=0, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=..., wait_proc=0x0, just_wait_proc=0) at ../../src/process.c:5571
#6  0x0000000000641d68 in kbd_buffer_get_event (kbp=0x7ffc18d6bfe8, used_mouse_menu=0x7ffc18d6c67f, end_time=0x0) at ../../src/keyboard.c:3866
#7  0x000000000063c86a in read_event_from_main_queue (end_time=0x0, local_getcjmp=0x7ffc18d6c420, used_mouse_menu=0x7ffc18d6c67f) at ../../src/keyboard.c:2156
#8  0x000000000063cbf9 in read_decoded_event_from_main_queue (end_time=0x0, local_getcjmp=0x7ffc18d6c420, prev_event=..., used_mouse_menu=0x7ffc18d6c67f) at ../../src/keyboard.c:2220
#9  0x000000000063ed11 in read_char (commandflag=1, map=..., prev_event=..., used_mouse_menu=0x7ffc18d6c67f, end_time=0x0) at ../../src/keyboard.c:2830
#10 0x000000000065036d in read_key_sequence (keybuf=0x7ffc18d6c820, prompt=..., dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9553
#11 0x000000000063a187 in command_loop_1 () at ../../src/keyboard.c:1350
#12 0x0000000000796ad7 in internal_condition_case (bfun=0x639d27 <command_loop_1>, handlers=..., hfun=0x639390 <cmd_error>) at ../../src/eval.c:1356
#13 0x0000000000639937 in command_loop_2 (ignore=...) at ../../src/keyboard.c:1091
#14 0x0000000000795fee in internal_catch (tag=..., func=0x63990e <command_loop_2>, arg=...) at ../../src/eval.c:1117
#15 0x00000000006398da in command_loop () at ../../src/keyboard.c:1070
#16 0x0000000000638ea4 in recursive_edit_1 () at ../../src/keyboard.c:714
#17 0x0000000000639085 in Frecursive_edit () at ../../src/keyboard.c:786
#18 0x000000000062f83e in main (argc=2, argv=0x7ffc18d6cd28) at ../../src/emacs.c:2062

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

[Tino Calancha]

On Tue, 4 Aug 2020, Bhavin Gandhi wrote:

>> If the problem is with display, then does it help to type (blindly)
>> "M-x redraw-display RET"?
>
> No it doesn't. The only thing worked was to create a new frame.
Bhavin, have you started the Emacs session with `Emacs -Q`?

In my case, I got the super-nasty scenario (ie, only works to create a new 
frame) when I load my custom libraries.

If I start with `Emacs -Q` it is less severe: te frame wakes up
if I input:
M-x

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

[Bhavin Gandhi]

On Wed, 5 Aug 2020 at 23:54, Tino Calancha <tino.calancha@gmail.com> wrote:
> >> If the problem is with display, then does it help to type (blindly)
> >> "M-x redraw-display RET"?
> >
> > No it doesn't. The only thing worked was to create a new frame.
> Bhavin, have you started the Emacs session with `Emacs -Q`?

No, this was a normal start with `emacs`.

> In my case, I got the super-nasty scenario (ie, only works to create a new
> frame) when I load my custom libraries.
>
> If I start with `Emacs -Q` it is less severe: te frame wakes up
> if I input:
> M-x

I had exactly the same behavior.

> here is the backtrace at the point when Emacs is stuck.

This backtrace was created with `emacs -Q` as Eli suggested initially.

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

[Tino Calancha]

On Thu, 6 Aug 2020, Bhavin Gandhi wrote:

>> Bhavin, have you started the Emacs session with `Emacs -Q`?
>
> No, this was a normal start with `emacs`.
> I had exactly the same behavior.
Thanks for the clarification.

>> here is the backtrace at the point when Emacs is stuck.
> This backtrace was created with `emacs -Q` as Eli suggested initially.
Thank you.  I hope Eli can get some hint from it.

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 22:53:15 +0530
> Cc: tino.calancha@gmail.com, 42655@debbugs.gnu.org, eggert@cs.ucla.edu, 
> 	monnier@iro.umontreal.ca, uyennhi.qm@gmail.com
> 
> Thanks for the suggestion, here is the backtrace at the point when Emacs
> is stuck. Adding it as an attachment.

Thanks, this backtrace says that Emacs is just waiting for input.

Please try this now, after attaching the debugger:

 (gdb) source /path/to/emacs/src/.gdbinit
 (gdb) p selected_frame
 (gdb) xtype

(replace "/path/to/emacs" with the actual absolute file name of the
Emacs source tree on your system).  Then post here the results.  And
please keep the GDB session running, don't exit it and don't kill
Emacs.

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

[Tino Calancha]

Eli Zaretskii <eliz@gnu.org> writes:

> Please try this now, after attaching the debugger:
>
>  (gdb) source /path/to/emacs/src/.gdbinit
>  (gdb) p selected_frame
>  (gdb) xtype

(gdb) 
source .gdbinit
&"source .gdbinit\n"
~"SIGINT is used by the debugger.\nAre you sure you want to change it? "
~"(y or n) [answered Y; input not from terminal]\n"
=cmd-param-changed,param="print pretty",value="on"
~"DISPLAY = :0\n"
~"TERM = xterm\n"
~"Breakpoint 1 at 0x59d9ad: file emacs.c, line 378.\n"
=breakpoint-created,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000059d9ad",func="terminate_due_to_signal",file="emacs.c",fullname="/home/calancha/soft/emacs-master/src/emacs.c",line="378",thread-groups=["i1"],times="0",original-location="terminate_due_to_signal"}
~"Breakpoint 2 at 0x56d2e3: file xterm.c, line 10135.\n"
=breakpoint-created,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x000000000056d2e3",func="x_error_quitter",file="xterm.c",fullname="/home/calancha/soft/emacs-master/src/xterm.c",line="10135",thread-groups=["i1"],times="0",original-location="x_error_quitter"}
^done
(gdb) 
p selected_frame
&"p selected_frame\n"
~"$1 = XIL(0x14f0835)\n"
^done
(gdb) 
xtype
&"xtype\n"
~"Lisp_Vectorlike"
~"\n"
~"PVEC_FRAME"
~"\n"
^done
(gdb) 

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

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Cc: Bhavin Gandhi <bhavin7392@gmail.com>,  uyennhi.qm@gmail.com,
>   42655@debbugs.gnu.org,  eggert@cs.ucla.edu,  monnier@iro.umontreal.ca
> Date: Wed, 05 Aug 2020 20:57:18 +0200
> 
> (gdb) 
> p selected_frame
> &"p selected_frame\n"
> ~"$1 = XIL(0x14f0835)\n"
> ^done
> (gdb) 
> xtype
> &"xtype\n"
> ~"Lisp_Vectorlike"
> ~"\n"
> ~"PVEC_FRAME"
> ~"\n"
> ^done
> (gdb) 

OK, now the important part:

  (gdb) p XFRAME (selected_frame)
  (gdb) p *$

The last command should display all the members of 'struct frame' that
correspond to the frame which doesn't redisplay.

Just to be sure: you are typing these commands in a situation where
you did NOT yet create another frame, this is the same frame which was
iconified by C-z, right?  I want to be sure we display the problematic
frame, not some other one.

Thanks.

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

[Bhavin Gandhi]

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

On Thu, 6 Aug 2020 at 07:59, Eli Zaretskii <eliz@gnu.org> wrote:
> OK, now the important part:
>
>   (gdb) p XFRAME (selected_frame)

This gave an error for me, I tried the following commands.

  (gdb) p XFRAME (selected_frame)
  No symbol "XFRAME" in current context.
  (gdb) p xframe (selected_frame)
  No symbol "xframe" in current context.

But xframe (selected_frame) worked.

>   (gdb) p *$
>
> The last command should display all the members of 'struct frame' that
> correspond to the frame which doesn't redisplay.

  (gdb) p selected_frame
  $1 = XIL(0x1e81975)
  (gdb) xtype
  Lisp_Vectorlike
  PVEC_FRAME
  (gdb) xframe (selected_frame)
  $2 = (struct frame *) 0x1e81970
  "emacs@toolbox"
  (gdb) p *$

Attaching the output as a file. This is the only frame in that Emacs
instance and it's frozen. I'm keeping gdb and Emacs running in case if
we need it.

[-- Attachment #2: bug-42655-struct-frame --]
[-- Type: application/octet-stream, Size: 4622 bytes --]

(gdb) source /home/bhavin/src/emacs/emacs-pretest-rpm/emacs-27.1/build-lucid/src/.gdbinit
<emacs-pretest-rpm/emacs-27.1/build-lucid/src/.gdbinit
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY = :0
TERM = dumb
Breakpoint 1 at 0x62d0f9: file ../../src/emacs.c, line 379.
Breakpoint 2 at 0x5d70d7: file ../../src/xterm.c, line 10137.
(gdb) p selected_frame
p selected_frame
$1 = XIL(0x1e81975)
(gdb) xtype
xtype
Lisp_Vectorlike
PVEC_FRAME
(gdb) xframe (selected_frame)
xframe (selected_frame)
$2 = (struct frame *) 0x1e81970
"emacs@toolbox"
(gdb) p *$
p *$
$3 = {
  header = {
    size = 4611686018578583579
  },
  name = XIL(0x1e88bc4),
  icon_name = XIL(0),
  title = XIL(0),
  parent_frame = XIL(0),
  focus_frame = XIL(0),
  root_window = XIL(0x1e8aee5),
  selected_window = XIL(0x1e8aee5),
  old_selected_window = XIL(0x1e8aee5),
  minibuffer_window = XIL(0x1e8b0f5),
  param_alist = XIL(0x1e38263),
  scroll_bars = XIL(0x1d83b05),
  condemned_scroll_bars = XIL(0),
  menu_bar_items = XIL(0x1f7f735),
  face_alist = XIL(0x1fb7b93),
  menu_bar_vector = XIL(0x1f9e335),
  buffer_predicate = XIL(0),
  buffer_list = XIL(0x1fbeb43),
  buried_buffer_list = XIL(0),
  tab_bar_window = XIL(0x1ef7db5),
  desired_tab_bar_string = XIL(0),
  current_tab_bar_string = XIL(0),
  tool_bar_window = XIL(0x1ef7fc5),
  desired_tool_bar_string = XIL(0),
  current_tool_bar_string = XIL(0x1f12914),
  font_data = XIL(0),
  tab_bar_items = XIL(0),
  tool_bar_items = XIL(0x20d39e5),
  face_cache = 0x1ec9cc0,
  last_tab_bar_item = -1,
  last_tool_bar_item = -1,
  menu_bar_items_used = 0,
  namebuf = 0x1e99360 "emacs",
  shell_position = 0x1f09c50 "=898x853",
  current_pool = 0x0,
  desired_pool = 0x0,
  desired_matrix = 0x0,
  current_matrix = 0x0,
  glyphs_initialized_p = true,
  resized_p = false,
  default_face_done_p = true,
  already_hscrolled_p = false,
  updated_p = true,
  minimize_tab_bar_window_p = false,
  minimize_tool_bar_window_p = false,
  fonts_changed = false,
  cursor_type_changed = false,
  redisplay = false,
  external_menu_bar = true,
  visible = 0,
  iconified = true,
  garbaged = false,
  wants_modeline = true,
  auto_raise = false,
  auto_lower = false,
  no_split = false,
  explicit_name = false,
  window_change = false,
  window_state_change = false,
  mouse_moved = true,
  pointer_invisible = false,
  frozen_window_starts = false,
  output_method = output_x_window,
  tooltip = false,
  want_fullscreen = FULLSCREEN_NONE,
  vertical_scroll_bar_type = vertical_scroll_bar_left,
  horizontal_scroll_bars = false,
  undecorated = false,
  override_redirect = false,
  skip_taskbar = false,
  no_focus_on_map = false,
  no_accept_focus = false,
  z_group = z_group_none,
  no_special_glyphs = false,
  new_pixelwise = false,
  can_set_window_size = true,
  after_make_frame = true,
  tab_bar_redisplayed = true,
  tab_bar_resized = false,
  tool_bar_redisplayed = true,
  tool_bar_resized = true,
  inhibit_horizontal_resize = false,
  inhibit_vertical_resize = false,
  face_change = false,
  inhibit_clear_image_cache = false,
  change_stamp = 3,
  number_of_windows = 2,
  tab_bar_lines = 0,
  tab_bar_height = 0,
  n_tab_bar_rows = 0,
  n_tab_bar_items = 0,
  tool_bar_lines = 2,
  tool_bar_height = 36,
  n_tool_bar_rows = 1,
  n_tool_bar_items = 13,
  decode_mode_spec_buffer = 0x1eff860 "",
  insert_line_cost = 0x0,
  delete_line_cost = 0x0,
  insert_n_lines_cost = 0x0,
  delete_n_lines_cost = 0x0,
  text_cols = 80,
  text_lines = 35,
  total_cols = 84,
  total_lines = 37,
  text_width = 880,
  text_height = 805,
  new_width = 0,
  new_height = 0,
  left_pos = 40,
  top_pos = 69,
  pixel_width = 914,
  pixel_height = 843,
  win_gravity = 1,
  size_hint_flags = 0,
  border_width = 0,
  internal_border_width = 1,
  right_divider_width = 0,
  bottom_divider_width = 0,
  left_fringe_width = 8,
  right_fringe_width = 8,
  fringe_cols = 2,
  menu_bar_lines = 0,
  menu_bar_height = 0,
  column_width = 11,
  line_height = 23,
  terminal = 0x1ccf7e0,
  output_data = {
    tty = 0x1d051e0,
    x = 0x1d051e0,
    w32 = 0x1d051e0,
    ns = 0x1d051e0
  },
  font_driver_list = 0x1ca5420,
  wait_event_type = 0,
  desired_cursor = FILLED_BOX_CURSOR,
  cursor_width = 1,
  blink_off_cursor = DEFAULT_CURSOR,
  blink_off_cursor_width = 0,
  config_scroll_bar_width = 16,
  config_scroll_bar_cols = 2,
  config_scroll_bar_height = 16,
  config_scroll_bar_lines = 1,
  cost_calculation_baud_rate = 19200,
  alpha = {-1, -1},
  gamma = 0,
  extra_line_spacing = 0,
  background_pixel = 16777215,
  foreground_pixel = 0
}

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

[Eli Zaretskii]

On August 6, 2020 8:41:12 AM GMT+03:00, Bhavin Gandhi <bhavin7392@gmail.com> wrote:
>
>  (gdb) p selected_frame
>  $1 = XIL(0x1e81975)
>  (gdb) xtype
>  Lisp_Vectorlike
>  PVEC_FRAME
>  (gdb) xframe (selected_frame)
>  $2 = (struct frame *) 0x1e81970
>  "emacs@toolbox"
>  (gdb) p *$
>
>Attaching the output as a file.


Thanks.  This clearly shows that Emacs considers the frame as being still iconified.

Please tell what does the following yield:

  (gdb) p *$2->output_data.x

This assumes that $2 is as you have show  previously, i.e. a pointer to struct frame that corresponds to the selected frame.

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

[Tino Calancha]

Eli Zaretskii <eliz@gnu.org> writes:

> Please tell what does the following yield:
>
>   (gdb) p *$2->output_data.x
>
> This assumes that $2 is as you have show  previously, i.e. a pointer to struct frame that corresponds to the selected frame.

(gdb) xframe (selected_frame)
$3 = (struct frame *) 0x234f888
"emacs@localhost.example.com"
(gdb) p *$3->output_data.x
$4 = {
  menubar_height = 29, 
  toolbar_top_height = 0, 
  toolbar_bottom_height = 0, 
  toolbar_left_width = 0, 
  toolbar_right_width = 0, 
  border_tile = 18874720, 
  normal_gc = 0x233c280, 
  reverse_gc = 0x223db40, 
  cursor_gc = 0x2251400, 
  window_desc = 18874715, 
  draw_desc = 18874716, 
  need_buffer_flip = false, 
  icon_desc = 0, 
  parent_desc = 8405122, 
  widget = 0x241c240, 
  column_widget = 0x221f610, 
  edit_widget = 0x2220390, 
  menubar_widget = 0x22f2b40, 
  icon_bitmap = 1, 
  font = 0x23ea680, 
  baseline_offset = 0, 
  fontset = 2, 
  cursor_pixel = 0, 
  border_pixel = 0, 
  mouse_pixel = 0, 
  cursor_foreground_pixel = 16777215, 
  scroll_bar_foreground_pixel = 18446744073709551615, 
  scroll_bar_background_pixel = 18446744073709551615, 
  scroll_bar_top_shadow_pixel = 18446744073709551615, 
  scroll_bar_bottom_shadow_pixel = 18446744073709551615, 
  text_cursor = 18874392, 
  nontext_cursor = 18874396, 
  modeline_cursor = 18874641, 
  hand_cursor = 18874645, 
  hourglass_cursor = 18874637, 
  horizontal_drag_cursor = 18874649, 
  vertical_drag_cursor = 18874653, 
  current_cursor = 18874396, 
  left_edge_cursor = 18874657, 
  top_left_corner_cursor = 18874661, 
  top_edge_cursor = 18874665, 
  top_right_corner_cursor = 18874669, 
  right_edge_cursor = 18874673, 
  bottom_right_corner_cursor = 18874677, 
  bottom_edge_cursor = 18874681, 
  bottom_left_corner_cursor = 18874685, 
  hourglass_window = 0, 
  wm_hints = {
    flags = 1, 
    input = 1, 
    initial_state = 0, 
    icon_pixmap = 18874722, 
    icon_window = 0, 
    icon_x = 0, 
    icon_y = 0, 
    icon_mask = 18874724, 
    window_group = 0
  }, 
  display_info = 0x222c5c0, 
  saved_menu_event = 0x248a670, 
  id = 1, 
  hourglass_p = false, 
  explicit_parent = false, 
  asked_for_visible = true, 
  has_been_visible = true, 
  wait_for_wm = true, 
  xic = 0x24269a0, 
  xic_style = 1028, 
  xic_xfs = 0x2423880, 
  black_relief = {
    gc = 0x21e8220, 
    pixel = 7566195
  }, 
  white_relief = {
    gc = 0x23e2ca0, 
    pixel = 15132390
  }, 
  relief_background = 12566463, 
  focus_state = 1, 
  move_offset_top = 0, 
  move_offset_left = 0, 
  cr_context = 0x22734b0, 
  cr_surface_desired_width = 674, 
  cr_surface_desired_height = 633
}
(gdb) 

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

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Cc: Bhavin Gandhi <bhavin7392@gmail.com>,  42655@debbugs.gnu.org,
>   eggert@cs.ucla.edu,  uyennhi.qm@gmail.com,  monnier@iro.umontreal.ca
> Date: Thu, 06 Aug 2020 10:13:06 +0200
> 
> >   (gdb) p *$2->output_data.x
> >
> > This assumes that $2 is as you have show  previously, i.e. a pointer to struct frame that corresponds to the selected frame.
> 
> (gdb) xframe (selected_frame)
> $3 = (struct frame *) 0x234f888
> "emacs@localhost.example.com"
> (gdb) p *$3->output_data.x
> $4 = {

Thanks.  Looks like we never get the MapNotify event from X windows?
Can you verify that, either by running the xev utility or by setting a
breakpoint in xterm.c:handle_one_xevent when MapNotify is handled, and
repeating the recipe?

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

[Eli Zaretskii]

> Date: Thu, 06 Aug 2020 16:47:00 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 42655@debbugs.gnu.org, eggert@cs.ucla.edu, uyennhi.qm@gmail.com,
>  bhavin7392@gmail.com, monnier@iro.umontreal.ca
> 
> Thanks.  Looks like we never get the MapNotify event from X windows?
> Can you verify that, either by running the xev utility or by setting a
> breakpoint in xterm.c:handle_one_xevent when MapNotify is handled, and
> repeating the recipe?

And one more thing: does it help to disable double-buffering?
(NEWS.26 explains how to do that.)

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

[Tino Calancha]

On Thu, 6 Aug 2020, Eli Zaretskii wrote:

> And one more thing: does it help to disable double-buffering?
> (NEWS.26 explains how to do that.)
This doesn't help :-(
[ I will investigate the other tips ]

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

[Tino Calancha]

On Thu, 6 Aug 2020, Eli Zaretskii wrote:

> Thanks.  Looks like we never get the MapNotify event from X windows?
> Can you verify that, either by running the xev utility or by setting a
> breakpoint in xterm.c:handle_one_xevent when MapNotify is handled, and
> repeating the recipe?

Set breakpoint at
xterm::8348
C-z ; frame is hidden
;; I select again the hidden frame
;; gdb doesn't jump to the breakpoint and the frame is 'cursed'
M-x
;; The frame wakes up and gdb reaches the breakpoint.

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

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Date: Thu, 6 Aug 2020 16:37:18 +0200 (CEST)
> cc: Tino Calancha <tino.calancha@gmail.com>, bhavin7392@gmail.com, 
>     42655@debbugs.gnu.org, eggert@cs.ucla.edu, uyennhi.qm@gmail.com, 
>     monnier@iro.umontreal.ca
> 
> > Thanks.  Looks like we never get the MapNotify event from X windows?
> > Can you verify that, either by running the xev utility or by setting a
> > breakpoint in xterm.c:handle_one_xevent when MapNotify is handled, and
> > repeating the recipe?
> 
> Set breakpoint at
> xterm::8348
> C-z ; frame is hidden
> ;; I select again the hidden frame
> ;; gdb doesn't jump to the breakpoint and the frame is 'cursed'
> M-x
> ;; The frame wakes up and gdb reaches the breakpoint.

And if you apply your patch, do we get MapNotify immediately after
"selecting again the hidden frame"?

Btw, what does "selecting again the hidden frame" mean, exactly?  What
gestures do you use to do that?  And what is your window manager?
(Bhavin, can you answer these questions for your case as well?)

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

[Tino Calancha]

Eli Zaretskii <eliz@gnu.org> writes:

>> Set breakpoint at
>> xterm::8348
>> C-z ; frame is hidden
>> ;; I select again the hidden frame
>> ;; gdb doesn't jump to the breakpoint and the frame is 'cursed'
>> M-x
>> ;; The frame wakes up and gdb reaches the breakpoint.
>
> And if you apply your patch, do we get MapNotify immediately after
> "selecting again the hidden frame"?
No, I don't.
With the patch, I get MapNotify right after I hit `C-z'.
That seems to be OK when I start with `emacs -Q', but it doesn't help
if I start emacs loading my custom stuff.


> Btw, what does "selecting again the hidden frame" mean, exactly?  What
> gestures do you use to do that?  And what is your window manager?

[This seems to be a problem affecting only my window manager (GNOME Shell)]

- After C-z, the frame dissapear from the screen.
- Note, there is no lower/upper bar with the APP iconified.
- To get such a frame again, you can do it in several ways:
  1. use shortcut to switch between apps (in my case M-TAB)
  2. if you the current focused window is another Emacs frame, then you
    can use the shortcut to switch between windows of same app
    (in my case M-`)
  3. Click upper-left corner menu 'Activities': now you can click in the
    'iconified' frame with the mouse
  Any of those 1-3 send the MapNotify


I have tested with other window managers in several OSes (Centos 8.1,
Ubuntu 18.04/20.04).
All window managers but GNOME Shell send the MapNotify
_right after_ you land in the previously iconified frame; that is, I only
can reproduce the bug when I am using GNOME Shell.


Desktop          window-manager       bug reproduced
KDE-plasma         kWin                 No
MATE               Metacity (Marco)     No
Fluxbox            Fluxbox              No
GNOME Classic      GNOME Shell          Yes
GNOME in Wayland   GNOME Shell          Yes

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

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Cc: 42655@debbugs.gnu.org,  eggert@cs.ucla.edu,  uyennhi.qm@gmail.com,
>   bhavin7392@gmail.com,  monnier@iro.umontreal.ca
> Date: Fri, 07 Aug 2020 13:47:42 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And if you apply your patch, do we get MapNotify immediately after
> > "selecting again the hidden frame"?
> No, I don't.
> With the patch, I get MapNotify right after I hit `C-z'.
> That seems to be OK when I start with `emacs -Q', but it doesn't help
> if I start emacs loading my custom stuff.

So in your customized session the patch doesn't really solve the
problem?  Or did I misunderstand?

> > Btw, what does "selecting again the hidden frame" mean, exactly?  What
> > gestures do you use to do that?  And what is your window manager?
> 
> [This seems to be a problem affecting only my window manager (GNOME Shell)]
> 
> - After C-z, the frame dissapear from the screen.
> - Note, there is no lower/upper bar with the APP iconified.
> - To get such a frame again, you can do it in several ways:
>   1. use shortcut to switch between apps (in my case M-TAB)
>   2. if you the current focused window is another Emacs frame, then you
>     can use the shortcut to switch between windows of same app
>     (in my case M-`)
>   3. Click upper-left corner menu 'Activities': now you can click in the
>     'iconified' frame with the mouse
>   Any of those 1-3 send the MapNotify

Now I'm confused: if MapNotify is sent when you use any of the 3
methods, then why doesn't the frame redisplay normally?  Previously
you said that MapNotify isn't received in this scenario.  What am I
missing?

> I have tested with other window managers in several OSes (Centos 8.1,
> Ubuntu 18.04/20.04).
> All window managers but GNOME Shell send the MapNotify
> _right after_ you land in the previously iconified frame; that is, I only
> can reproduce the bug when I am using GNOME Shell.

OK, thanks.  Bhavin, are you also using the same window manager?

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

[Bhavin Gandhi]

On Fri, 7 Aug 2020 at 17:35, Eli Zaretskii <eliz@gnu.org> wrote:
> > I have tested with other window managers in several OSes (Centos 8.1,
> > Ubuntu 18.04/20.04).
> > All window managers but GNOME Shell send the MapNotify
> > _right after_ you land in the previously iconified frame; that is, I only
> > can reproduce the bug when I am using GNOME Shell.
>
> OK, thanks.  Bhavin, are you also using the same window manager?

Yes, I'm using GNOME on Wayland too. And I hit M-TAB to return to Emacs.

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

[Tino Calancha]

Eli Zaretskii <eliz@gnu.org> writes:

> So in your customized session the patch doesn't really solve the
> problem?  Or did I misunderstand?
Exactly.  My patches fixes _only_ an Emacs -Q session: for me,
it doesn't work in a normal custom session.

>> > Btw, what does "selecting again the hidden frame" mean, exactly?  What
>> > gestures do you use to do that?  And what is your window manager?
>> 
>> [This seems to be a problem affecting only my window manager (GNOME Shell)]
>> 
>> - After C-z, the frame dissapear from the screen.
>> - Note, there is no lower/upper bar with the APP iconified.
>> - To get such a frame again, you can do it in several ways:
>>   1. use shortcut to switch between apps (in my case M-TAB)
>>   2. if you the current focused window is another Emacs frame, then you
>>     can use the shortcut to switch between windows of same app
>>     (in my case M-`)
>>   3. Click upper-left corner menu 'Activities': now you can click in the
>>     'iconified' frame with the mouse
>>   Any of those 1-3 send the MapNotify
>
> Now I'm confused: if MapNotify is sent when you use any of the 3
> methods, then why doesn't the frame redisplay normally?
Sorry, for the confusion.  It redisplay normally in a `emacs -Q` session only.

> Previously
> you said that MapNotify isn't received in this scenario.
I have tested a rich casuistic: MapNotify is never recived in my 'custom
sessions'.

Following tables summarizes the situation:

=== window manager:  GNOME Shell ===

--- unpatched Emacs-27 --- 
                  emacs -Q   custom libs

MapNotify at        never      never
bug?                 yes       yes

--- Emacs-27 with patch --- 
                   emacs -Q   custom libs

MapNotify at       iconify   never
bug?                 no       yes


=== window manager:  Other than GNOME Shell ===

--- unpatched Emacs-27 --- 
                  emacs -Q       custom libs

MapNotify at        de-iconify   de-iconify
bug?                no           no

[In this case patched/unpatched makes no difference]
Except for GNOME Shell, for all win managers that I have tested,
the MapNotify comes always at the moment of de-iconify.


In Summary:
- The bugs happens when Emacs is compiled with Lucid and run in an
  environment using GNOME Shell as window manager.
- The patch works for `emacs -Q`
- The patch doesn't work in my cursom sessions :-(

Possible workarounds for me right row:
  1. Use a different window manager.
  2. Or, compile Emacs with GTK.

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

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Cc: 42655@debbugs.gnu.org,  eggert@cs.ucla.edu,  uyennhi.qm@gmail.com,
>   bhavin7392@gmail.com,  monnier@iro.umontreal.ca
> Date: Fri, 07 Aug 2020 16:01:11 +0200
> 
> Following tables summarizes the situation:
> 
> === window manager:  GNOME Shell ===
> 
> --- unpatched Emacs-27 --- 
>                   emacs -Q   custom libs
> 
> MapNotify at        never      never
> bug?                 yes       yes
> 
> --- Emacs-27 with patch --- 
>                    emacs -Q   custom libs
> 
> MapNotify at       iconify   never
> bug?                 no       yes
> 
> 
> === window manager:  Other than GNOME Shell ===
> 
> --- unpatched Emacs-27 --- 
>                   emacs -Q       custom libs
> 
> MapNotify at        de-iconify   de-iconify
> bug?                no           no

Thanks.

Does anyone here have a clue why we don't get MapNotify in the GNOME
Shell case?  I'm afraid I'm almost out of my depth here.

Tino, could you please use 'xev' to show which X events _are_ being
delivered to Emacs after you press M-TAB or do any of the other 2
gestures that are supposed to de-iconify the frame?

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

[Tino Calancha]

Eli Zaretskii <eliz@gnu.org> writes:

> Does anyone here have a clue why we don't get MapNotify in the GNOME
> Shell case?
All window managers I have tested so far (except Gnome Shell) agree on the
following:

they send a 'VisibilityNotify event' when you select back the previously
iconified window.

Gnome Shell do not send such an event even when users choose 'Gnome
Classic', which uses a panel that displays the iconified apps.

[Design decision or Gnome bug? I haven't searched that much about this,
but I think gnome Shell should send that event as everyone else: this
migth affect other APPS, not only Emacs]

> Tino, could you please use 'xev' to show which X events _are_ being
> delivered to Emacs after you press M-TAB or do any of the other 2
> gestures that are supposed to de-iconify the frame?
Here is the comparison between window managers.
for easier navigations, I recommend to copy the
following lines and display it inside Emacs in a org mode buffer:

--8<-----------------------------cut here---------------start------------->8---
* xev: fluxbox
** C-z

KeyRelease event, serial 21, synthetic NO, window 0x1a00027,
    root 0x215, subw 0x0, time 5924861, (981,179), root:(4949,427),
    state 0x10, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 21, synthetic NO, window 0x1a00027,
    root 0x215, subw 0x0, time 5924861, (981,179), root:(4949,427),
    state 0x10, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 21, synthetic NO, window 0x1a00027,
    root 0x215, subw 0x0, time 5925229, (981,179), root:(4949,427),
    state 0x14, keycode 52 (keysym 0x7a, z), same_screen YES,
    XLookupString gives 1 bytes: (1a) ""
    XFilterEvent returns: False

KeyPress event, serial 21, synthetic NO, window 0x1a00027,
    root 0x215, subw 0x0, time 5925229, (981,179), root:(4949,427),
    state 0x14, keycode 52 (keysym 0x7a, z), same_screen YES,
    XLookupString gives 1 bytes: (1a) ""
    XmbLookupString gives 1 bytes: (1a) ""
    XFilterEvent returns: False

PropertyNotify event, serial 21, synthetic NO, window 0x1a00027,
    atom 0x1a8 (_NET_WM_ALLOWED_ACTIONS), time 5925236, state PropertyNewValue

PropertyNotify event, serial 22, synthetic NO, window 0x1a00027,
    atom 0x19b (_NET_WM_STATE), time 5925237, state PropertyNewValue

FocusOut event, serial 23, synthetic NO, window 0x1a00027,
    mode NotifyNormal, detail NotifyNonlinear

PropertyNotify event, serial 23, synthetic NO, window 0x1a00027,
    atom 0x16d (WM_STATE), time 5925237, state PropertyNewValue

UnmapNotify event, serial 23, synthetic NO, window 0x1a00027,
    event 0x1a00027, window 0x1a00027, from_configure NO

ConfigureNotify event, serial 24, synthetic YES, window 0x1a00027,
    event 0x1a00027, window 0x1a00027, (3968,248), width 674, height 680,
    border_width 0, above 0x0, override NO
** De-iconify (M-TAB, M-`, click w/ mouse, etc)

PropertyNotify event, serial 24, synthetic NO, window 0x1a00027,
    atom 0x1a8 (_NET_WM_ALLOWED_ACTIONS), time 5996447, state PropertyNewValue

PropertyNotify event, serial 24, synthetic NO, window 0x1a00027,
    atom 0x19b (_NET_WM_STATE), time 5996447, state PropertyDelete

MapNotify event, serial 24, synthetic NO, window 0x1a00027,
    event 0x1a00027, window 0x1a00027, override NO

VisibilityNotify event, serial 24, synthetic NO, window 0x1a00027,
    state VisibilityPartiallyObscured

PropertyNotify event, serial 24, synthetic NO, window 0x1a00027,
    atom 0x16d (WM_STATE), time 5996449, state PropertyNewValue

VisibilityNotify event, serial 24, synthetic NO, window 0x1a00027,
    state VisibilityUnobscured

FocusIn event, serial 24, synthetic NO, window 0x1a00027,
    mode NotifyWhileGrabbed, detail NotifyNonlinear

KeymapNotify event, serial 24, synthetic NO, window 0x0,
    keys:  109 0   4294967168 0   0   0   0   0   0   0   0   0   0   16  0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

ConfigureNotify event, serial 24, synthetic NO, window 0x1a00027,
    event 0x1a00027, window 0x1a00027, (0,18), width 674, height 680,
    border_width 0, above 0x400eb4, override NO

ConfigureNotify event, serial 24, synthetic YES, window 0x1a00027,
    event 0x1a00027, window 0x1a00027, (3968,248), width 674, height 680,
    border_width 0, above 0x0, override NO

FocusIn event, serial 24, synthetic NO, window 0x1a00027,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 24, synthetic NO, window 0x0,
    keys:  3   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

* xev: mate
** C-z

KeyRelease event, serial 19, synthetic NO, window 0x3c00028,
    root 0x215, subw 0x0, time 1071389, (99,1997), root:(509,2158),
    state 0x10, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 19, synthetic NO, window 0x3c00028,
    root 0x215, subw 0x0, time 1071389, (99,1997), root:(509,2158),
    state 0x10, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 22, synthetic NO, window 0x3c00028,
    root 0x215, subw 0x0, time 1071805, (99,1997), root:(509,2158),
    state 0x14, keycode 52 (keysym 0x7a, z), same_screen YES,
    XLookupString gives 1 bytes: (1a) ""
    XFilterEvent returns: False

KeyPress event, serial 22, synthetic NO, window 0x3c00028,
    root 0x215, subw 0x0, time 1071805, (99,1997), root:(509,2158),
    state 0x14, keycode 52 (keysym 0x7a, z), same_screen YES,
    XLookupString gives 1 bytes: (1a) ""
    XmbLookupString gives 1 bytes: (1a) ""
    XFilterEvent returns: False

PropertyNotify event, serial 22, synthetic NO, window 0x3c00028,
    atom 0x202 (_NET_WM_ALLOWED_ACTIONS), time 1071811, state PropertyNewValue

FocusOut event, serial 22, synthetic NO, window 0x3c00028,
    mode NotifyNormal, detail NotifyNonlinear

UnmapNotify event, serial 22, synthetic NO, window 0x3c00028,
    event 0x3c00028, window 0x3c00028, from_configure NO

PropertyNotify event, serial 22, synthetic NO, window 0x3c00028,
    atom 0x1c0 (WM_STATE), time 1071812, state PropertyNewValue

PropertyNotify event, serial 22, synthetic NO, window 0x3c00028,
    atom 0x17e (_NET_WM_STATE), time 1071812, state PropertyNewValue

PropertyNotify event, serial 24, synthetic NO, window 0x3c00028,
    atom 0x17e (_NET_WM_STATE), time 1071813, state PropertyNewValue
** De-iconify (M-TAB, M-`, click w/ mouse, etc)

PropertyNotify event, serial 24, synthetic NO, window 0x3c00028,
    atom 0x202 (_NET_WM_ALLOWED_ACTIONS), time 1140295, state PropertyNewValue

MapNotify event, serial 24, synthetic NO, window 0x3c00028,
    event 0x3c00028, window 0x3c00028, override NO

VisibilityNotify event, serial 24, synthetic NO, window 0x3c00028,
    state VisibilityUnobscured

PropertyNotify event, serial 24, synthetic NO, window 0x3c00028,
    atom 0x1c0 (WM_STATE), time 1140303, state PropertyNewValue

PropertyNotify event, serial 24, synthetic NO, window 0x3c00028,
    atom 0x17e (_NET_WM_STATE), time 1140303, state PropertyNewValue

FocusIn event, serial 24, synthetic NO, window 0x3c00028,
    mode NotifyNormal, detail NotifyNonlinear

KeymapNotify event, serial 24, synthetic NO, window 0x0,
    keys:  0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

PropertyNotify event, serial 24, synthetic NO, window 0x3c00028,
    atom 0x17e (_NET_WM_STATE), time 1140305, state PropertyNewValue

* xev: plasma-wayland
** C-z

KeyRelease event, serial 19, synthetic NO, window 0x14000b5,
    root 0x3a1, subw 0x0, time 364008, (-1280,444), root:(1025,698),
    state 0x0, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 19, synthetic NO, window 0x14000b5,
    root 0x3a1, subw 0x0, time 364008, (-1280,444), root:(1025,698),
    state 0x0, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 22, synthetic NO, window 0x14000b5,
    root 0x3a1, subw 0x0, time 364233, (-1280,444), root:(1025,698),
    state 0x4, keycode 52 (keysym 0x7a, z), same_screen YES,
    XLookupString gives 1 bytes: (1a) ""
    XFilterEvent returns: False

KeyPress event, serial 22, synthetic NO, window 0x14000b5,
    root 0x3a1, subw 0x0, time 364233, (-1280,444), root:(1025,698),
    state 0x4, keycode 52 (keysym 0x7a, z), same_screen YES,
    XLookupString gives 1 bytes: (1a) ""
    XmbLookupString gives 1 bytes: (1a) ""
    XFilterEvent returns: False

PropertyNotify event, serial 22, synthetic NO, window 0x14000b5,
    atom 0x152 (_NET_WM_STATE), time 364234, state PropertyNewValue

FocusOut event, serial 22, synthetic NO, window 0x14000b5,
    mode NotifyNormal, detail NotifyNonlinear

UnmapNotify event, serial 22, synthetic NO, window 0x14000b5,
    event 0x14000b5, window 0x14000b5, from_configure NO

PropertyNotify event, serial 22, synthetic NO, window 0x14000b5,
    atom 0x108 (WM_STATE), time 364235, state PropertyNewValue

PropertyNotify event, serial 22, synthetic NO, window 0x14000b5,
    atom 0x152 (_NET_WM_STATE), time 364235, state PropertyNewValue

** De-iconify (M-TAB, M-`, click w/ mouse, etc)

PropertyNotify event, serial 23, synthetic NO, window 0x14000b5,
    atom 0x152 (_NET_WM_STATE), time 387978, state PropertyNewValue

MapNotify event, serial 23, synthetic NO, window 0x14000b5,
    event 0x14000b5, window 0x14000b5, override NO

VisibilityNotify event, serial 23, synthetic NO, window 0x14000b5,
    state VisibilityUnobscured

PropertyNotify event, serial 23, synthetic NO, window 0x14000b5,
    atom 0x108 (WM_STATE), time 387979, state PropertyNewValue

FocusIn event, serial 23, synthetic NO, window 0x14000b5,
    mode NotifyNormal, detail NotifyNonlinear

KeymapNotify event, serial 23, synthetic NO, window 0x0,
    keys:  4294967221 0   0   0   0   0   0   0   0   0   0   0   0   16  0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

PropertyNotify event, serial 23, synthetic NO, window 0x14000b5,
    atom 0x152 (_NET_WM_STATE), time 387986, state PropertyNewValue

* xev: gnome-shell-gnome-wayland
** C-z

KeyRelease event, serial 20, synthetic NO, window 0x8000ba,
    root 0x3a0, subw 0x0, time 1658527, (-140,569), root:(873,742),
    state 0x0, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 20, synthetic NO, window 0x8000ba,
    root 0x3a0, subw 0x0, time 1658527, (-140,569), root:(873,742),
    state 0x0, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 23, synthetic NO, window 0x8000ba,
    root 0x3a0, subw 0x0, time 1658687, (-140,569), root:(873,742),
    state 0x4, keycode 52 (keysym 0x7a, z), same_screen YES,
    XLookupString gives 1 bytes: (1a) ""
    XFilterEvent returns: False

KeyPress event, serial 23, synthetic NO, window 0x8000ba,
    root 0x3a0, subw 0x0, time 1658687, (-140,569), root:(873,742),
    state 0x4, keycode 52 (keysym 0x7a, z), same_screen YES,
    XLookupString gives 1 bytes: (1a) ""
    XmbLookupString gives 1 bytes: (1a) ""
    XFilterEvent returns: False

PropertyNotify event, serial 23, synthetic NO, window 0x8000ba,
    atom 0x12d (WM_STATE), time 1658695, state PropertyNewValue

PropertyNotify event, serial 23, synthetic NO, window 0x8000ba,
    atom 0x10d (_NET_WM_STATE), time 1658695, state PropertyNewValue

PropertyNotify event, serial 23, synthetic NO, window 0x8000ba,
    atom 0x193 (_GTK_EDGE_CONSTRAINTS), time 1658695, state PropertyNewValue

FocusOut event, serial 23, synthetic NO, window 0x8000ba,
    mode NotifyNormal, detail NotifyNonlinear

PropertyNotify event, serial 23, synthetic NO, window 0x8000ba,
    atom 0x10d (_NET_WM_STATE), time 1658695, state PropertyNewValue

PropertyNotify event, serial 23, synthetic NO, window 0x8000ba,
    atom 0x193 (_GTK_EDGE_CONSTRAINTS), time 1658695, state PropertyNewValue

PropertyNotify event, serial 24, synthetic NO, window 0x8000ba,
    atom 0x10d (_NET_WM_STATE), time 1658712, state PropertyNewValue

PropertyNotify event, serial 24, synthetic NO, window 0x8000ba,
    atom 0x193 (_GTK_EDGE_CONSTRAINTS), time 1658712, state PropertyNewValue
** De-iconify (M-TAB, M-`, click w/ mouse, etc)

PropertyNotify event, serial 24, synthetic NO, window 0x8000ba,
    atom 0x12d (WM_STATE), time 1703120, state PropertyNewValue

PropertyNotify event, serial 24, synthetic NO, window 0x8000ba,
    atom 0x10d (_NET_WM_STATE), time 1703120, state PropertyNewValue

PropertyNotify event, serial 24, synthetic NO, window 0x8000ba,
    atom 0x193 (_GTK_EDGE_CONSTRAINTS), time 1703120, state PropertyNewValue

FocusIn event, serial 24, synthetic NO, window 0x8000ba,
    mode NotifyNormal, detail NotifyNonlinear

KeymapNotify event, serial 24, synthetic NO, window 0x0,
    keys:  13  0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

PropertyNotify event, serial 24, synthetic NO, window 0x8000ba,
    atom 0x10d (_NET_WM_STATE), time 1703123, state PropertyNewValue

PropertyNotify event, serial 24, synthetic NO, window 0x8000ba,
    atom 0x193 (_GTK_EDGE_CONSTRAINTS), time 1703123, state PropertyNewValue

PropertyNotify event, serial 24, synthetic NO, window 0x8000ba,
    atom 0x10d (_NET_WM_STATE), time 1703145, state PropertyNewValue

PropertyNotify event, serial 24, synthetic NO, window 0x8000ba,
    atom 0x193 (_GTK_EDGE_CONSTRAINTS), time 1703145, state PropertyNewValue

* xev: gnome-shell-gnome-classic
** C-z

KeyRelease event, serial 23, synthetic NO, window 0x22000ba,
    root 0x215, subw 0x0, time 609608, (-1390,576), root:(783,764),
    state 0x0, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 23, synthetic NO, window 0x22000ba,
    root 0x215, subw 0x0, time 609608, (-1390,576), root:(783,764),
    state 0x0, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 23, synthetic NO, window 0x22000ba,
    root 0x215, subw 0x0, time 609768, (-1390,576), root:(783,764),
    state 0x4, keycode 52 (keysym 0x7a, z), same_screen YES,
    XLookupString gives 1 bytes: (1a) ""
    XFilterEvent returns: False

KeyPress event, serial 23, synthetic NO, window 0x22000ba,
    root 0x215, subw 0x0, time 609768, (-1390,576), root:(783,764),
    state 0x4, keycode 52 (keysym 0x7a, z), same_screen YES,
    XLookupString gives 1 bytes: (1a) ""
    XmbLookupString gives 1 bytes: (1a) ""
    XFilterEvent returns: False

PropertyNotify event, serial 23, synthetic NO, window 0x22000ba,
    atom 0x1bb (WM_STATE), time 609783, state PropertyNewValue

PropertyNotify event, serial 23, synthetic NO, window 0x22000ba,
    atom 0x17e (_NET_WM_STATE), time 609783, state PropertyNewValue

PropertyNotify event, serial 23, synthetic NO, window 0x22000ba,
    atom 0x1ca (_GTK_EDGE_CONSTRAINTS), time 609783, state PropertyNewValue

FocusOut event, serial 23, synthetic NO, window 0x22000ba,
    mode NotifyNormal, detail NotifyNonlinear

PropertyNotify event, serial 24, synthetic NO, window 0x22000ba,
    atom 0x17e (_NET_WM_STATE), time 609788, state PropertyNewValue

PropertyNotify event, serial 24, synthetic NO, window 0x22000ba,
    atom 0x1ca (_GTK_EDGE_CONSTRAINTS), time 609788, state PropertyNewValue
** De-iconify (M-TAB, M-`, click w/ mouse, etc)

PropertyNotify event, serial 24, synthetic NO, window 0x22000ba,
    atom 0x1bb (WM_STATE), time 657505, state PropertyNewValue

PropertyNotify event, serial 24, synthetic NO, window 0x22000ba,
    atom 0x17e (_NET_WM_STATE), time 657505, state PropertyNewValue

PropertyNotify event, serial 24, synthetic NO, window 0x22000ba,
    atom 0x1ca (_GTK_EDGE_CONSTRAINTS), time 657505, state PropertyNewValue

FocusIn event, serial 24, synthetic NO, window 0x22000ba,
    mode NotifyWhileGrabbed, detail NotifyNonlinear

KeymapNotify event, serial 24, synthetic NO, window 0x0,
    keys:  126 0   0   0   0   0   2   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

FocusIn event, serial 24, synthetic NO, window 0x22000ba,
    mode NotifyUngrab, detail NotifyNonlinear

KeymapNotify event, serial 24, synthetic NO, window 0x0,
    keys:  3   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

PropertyNotify event, serial 24, synthetic NO, window 0x22000ba,
    atom 0x17e (_NET_WM_STATE), time 657520, state PropertyNewValue

PropertyNotify event, serial 24, synthetic NO, window 0x22000ba,
    atom 0x1ca (_GTK_EDGE_CONSTRAINTS), time 657520, state PropertyNewValue


--8<-----------------------------cut here---------------end--------------->8---

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

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Cc: 42655@debbugs.gnu.org,  eggert@cs.ucla.edu,  uyennhi.qm@gmail.com,
>   bhavin7392@gmail.com,  monnier@iro.umontreal.ca
> Date: Sat, 08 Aug 2020 13:52:53 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Does anyone here have a clue why we don't get MapNotify in the GNOME
> > Shell case?
> All window managers I have tested so far (except Gnome Shell) agree on the
> following:
> 
> they send a 'VisibilityNotify event' when you select back the previously
> iconified window.

Our code expects MapNotify.  My reading of the code in xterm.c is that
we do nothing special when we receive VisibilityNotify.

I see in xterm.c that we already have some special treatment of the
Gnome Shell, see below.  Could you please put a breakpoint there, and
tell why we don't set the frame's visible flag and don't reset its
iconified flag when the PropertyNotify event is received?  Your event
log seems to indicate we get quite a few of PropertyNotify events when
the frame is de-iconified.

> Here is the comparison between window managers.
> for easier navigations, I recommend to copy the
> following lines and display it inside Emacs in a org mode buffer:

Thanks, this is very useful.

Here's the snippet from xterm.c that deals with PropertyNotify:

    case PropertyNotify:
      x_display_set_last_user_time (dpyinfo, event->xproperty.time);
      f = x_top_window_to_frame (dpyinfo, event->xproperty.window);
      if (f && event->xproperty.atom == dpyinfo->Xatom_net_wm_state)
	{
          bool not_hidden = x_handle_net_wm_state (f, &event->xproperty);
	  if (not_hidden && FRAME_ICONIFIED_P (f))
	    {
	      /* Gnome shell does not iconify us when C-z is pressed.
		 It hides the frame.  So if our state says we aren't
		 hidden anymore, treat it as deiconified.  */
	      SET_FRAME_VISIBLE (f, 1);
	      SET_FRAME_ICONIFIED (f, false);
	      f->output_data.x->has_been_visible = true;
	      inev.ie.kind = DEICONIFY_EVENT;
	      XSETFRAME (inev.ie.frame_or_window, f);
	    }
	  else if (! not_hidden && ! FRAME_ICONIFIED_P (f))
	    {
	      SET_FRAME_VISIBLE (f, 0);
	      SET_FRAME_ICONIFIED (f, true);
	      inev.ie.kind = ICONIFY_EVENT;
	      XSETFRAME (inev.ie.frame_or_window, f);
	    }
	}

      x_handle_property_notify (&event->xproperty);
      xft_settings_event (dpyinfo, event);
      goto OTHER;

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

[Tino Calancha]

Eli Zaretskii <eliz@gnu.org> writes:

CC Daniel whom might have some ideas.

A bit of context.
Some WMs (e.g. Mutter in Gnome Shell or Muffin) follow a new trend: they
don't unmap windows when they are iconified.
https://gitlab.gnome.org/GNOME/mutter/-/issues/185

Since they are never unmapped, the windows are not mapped back when they
are deconified.  This might cause an unresponsive frame in Lucid Emacs
builds, because we redisplay when we get the MapNotify signal
(that we don't receive in those WMs).

Apparentely, GTK3 Emacs builds are not affected by this issue.

> I see in xterm.c that we already have some special treatment of the
> Gnome Shell, see below.  Could you please put a breakpoint there, and
> tell why we don't set the frame's visible flag and don't reset its
> iconified flag when the PropertyNotify event is received?  Your event
> log seems to indicate we get quite a few of PropertyNotify events when
> the frame is de-iconified.
That break point is only reached while creating the frame or clicking
the menu bars.  Once the frame is created, I am not able to reach that
part by minimize/unminimize.

I have printed out `event->type` right before the switch(event->type)
I enter the break point at PropertyNotify when `event->type` equals 28.
The xev utility is printing out PropertyNotify for a bunch of different
values of `event->type`, not just for 28.


Naively, I can workaround this issue by checking for an iconified frame at
FocusIn:  this fixes this issue in both `emacs -Q` and my
custom Emacs session.

I am not sure if this is a convenient way.  We might also want to make
it more specific for checking some condition.


--8<-----------------------------cut here---------------start------------->8---
commit d9b06705a045336e1ef307cdfd523a1d5cbb9e7a
Author: Tino Calancha <ccalancha@suse.com>
Date:   Mon Aug 10 19:32:17 2020 +0200

    Fix bug 42655
    
    Some WMs (e.g. mutter in Gnome Shell) don't unmap iconized windows,
    thus we won't get a MapNotify when deconifying them.
    Check if we are deconifying a window elsewhere.
    
    - src/xterm.c (handle_one_xevent):
    Check for window deconify when receiving a FocusIn signal.

diff --git a/src/xterm.c b/src/xterm.c
index 6340700cb8..de1da2d4d4 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -8760,6 +8760,19 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       goto OTHER;
 
     case FocusIn:
+      /* Some WMs (e.g. Mutter in Gnome Shell), don't unmap minimized/iconified windows;
+         thus, for those WMs we won't get a MapNotify when unminimizing/deconifying.
+         Check here if we are deconizing a window (Bug42655). */
+      f = any;
+      if (f && FRAME_ICONIFIED_P (f))
+	{
+          SET_FRAME_VISIBLE (f, 1);
+          SET_FRAME_ICONIFIED (f, false);
+          f->output_data.x->has_been_visible = true;
+          inev.ie.kind = DEICONIFY_EVENT;
+          XSETFRAME (inev.ie.frame_or_window, f);
+        }
+
       x_detect_focus_change (dpyinfo, any, event, &inev.ie);
       goto OTHER;
 
--8<-----------------------------cut here---------------end--------------->8---
In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.21, cairo version 1.16.0)
 of 2020-08-09 built on localhost.example.com
Repository revision: dcce2b57bb91d490787dffd437b61196f1029b41
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: openSUSE Tumbleweed

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

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Cc: 42655@debbugs.gnu.org,  eggert@cs.ucla.edu,  uyennhi.qm@gmail.com,
>   bhavin7392@gmail.com,  monnier@iro.umontreal.ca, dancol@dancol.org
> Date: Mon, 10 Aug 2020 19:52:39 +0200
> 
> > I see in xterm.c that we already have some special treatment of the
> > Gnome Shell, see below.  Could you please put a breakpoint there, and
> > tell why we don't set the frame's visible flag and don't reset its
> > iconified flag when the PropertyNotify event is received?  Your event
> > log seems to indicate we get quite a few of PropertyNotify events when
> > the frame is de-iconified.
> That break point is only reached while creating the frame or clicking
> the menu bars.  Once the frame is created, I am not able to reach that
> part by minimize/unminimize.
> 
> I have printed out `event->type` right before the switch(event->type)
> I enter the break point at PropertyNotify when `event->type` equals 28.
> The xev utility is printing out PropertyNotify for a bunch of different
> values of `event->type`, not just for 28.
> 
> 
> Naively, I can workaround this issue by checking for an iconified frame at
> FocusIn:  this fixes this issue in both `emacs -Q` and my
> custom Emacs session.

That would be my next idea, so please go ahead and install this.  And
thanks for all the footwork in investigating this issue.

> +      /* Some WMs (e.g. Mutter in Gnome Shell), don't unmap minimized/iconified windows;
> +         thus, for those WMs we won't get a MapNotify when unminimizing/deconifying.
> +         Check here if we are deconizing a window (Bug42655). */

Please M-q in this comment, to make its lines shorter.

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

[Tino Calancha]

Eli Zaretskii <eliz@gnu.org> writes:

 
>> Naively, I can workaround this issue by checking for an iconified frame at
>> FocusIn:  this fixes this issue in both `emacs -Q` and my
>> custom Emacs session.
>
> That would be my next idea, so please go ahead and install this.  And
> thanks for all the footwork in investigating this issue.

Thank you for your guidance.  It was crucial.

Pushed fix into emacs-27 branch as commit
'Prevent from frozen frame after `C-z' in Lucid builds'
(3c4edfd85ee8f49e40715a400a1fc65950e07482)