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

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Tino Calancha-2
X-Debbugs-Cc: Stefan Monnier <[hidden email]>, Paul Eggert <[hidden email]>, <[hidden email]>
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))



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Tino Calancha <[hidden email]>
> Date: Sat, 01 Aug 2020 20:46:03 +0200
> Cc: paul eggert <[hidden email]>, stefan monnier <[hidden email]>,
>  [hidden email]
>
> 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?



Reply | Threaded
Open this post in threaded view
|

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

Tino Calancha-2
In reply to this post by Tino Calancha-2
Tino Calancha <[hidden email]> 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 <[hidden email]>
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 <[hidden email]>
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



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Tino Calancha <[hidden email]>
> Date: Sun, 02 Aug 2020 15:07:32 +0200
> Cc: paul eggert <[hidden email]>, stefan monnier <[hidden email]>,
>  [hidden email]
>
> Tino Calancha <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> 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?



Reply | Threaded
Open this post in threaded view
|

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

Tino Calancha-2

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





Reply | Threaded
Open this post in threaded view
|

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




Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Tino Calancha-2
> From: Tino Calancha <[hidden email]>
> Date: Mon, 3 Aug 2020 21:46:49 +0200 (CEST)
> cc: Tino Calancha <[hidden email]>, [hidden email],
>     [hidden email], [hidden email], [hidden email]
>
> How about in Windows? Have you seen this bug?

No, nothing like that.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
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 <[hidden email]> wrote:
From: Tino Calancha <[hidden email]>
Date: Mon, 3 Aug 2020 21:46:49 +0200 (CEST)
cc: Tino Calancha <[hidden email]>, [hidden email],
[hidden email], [hidden email], [hidden email]

How about in Windows? Have you seen this bug?

No, nothing like that.





--
נשלח ממכשיר האנדרואיד שלי בעזרת אפליקציית הדואר K-9. סלח לי על הקצרנות.
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
> Cc: [hidden email], [hidden email], [hidden email]
>
> 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"?



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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?



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Bhavin Gandhi <[hidden email]>
> Date: Wed, 5 Aug 2020 00:23:09 +0530
> Cc: [hidden email], [hidden email], [hidden email],
> [hidden email], [hidden email]
>
> On Tue, 4 Aug 2020 at 22:11, Eli Zaretskii <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Bhavin Gandhi
On Wed, 5 Aug 2020 at 00:37, Eli Zaretskii <[hidden email]> 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.

bug-42655-backtrace (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Tino Calancha-2
In reply to this post by Bhavin Gandhi


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




Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Tino Calancha-2


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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Bhavin Gandhi
> From: Bhavin Gandhi <[hidden email]>
> Date: Wed, 5 Aug 2020 22:53:15 +0530
> Cc: [hidden email], [hidden email], [hidden email],
> [hidden email], [hidden email]
>
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Tino Calancha-2
Eli Zaretskii <[hidden email]> 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)



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Tino Calancha <[hidden email]>
> Cc: Bhavin Gandhi <[hidden email]>,  [hidden email],
>   [hidden email],  [hidden email],  [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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.



12