bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eric Abrahamsen]

Hi all,

I rebuilt Emacs on one of my machines yesterday, and am seeing odd
behavior (with emacs -Q): I use a tiling window manager, which
fullscreens frames by default, and when I open multiple Emacs frames,
only one of them redisplays correctly, the others stay "frozen" and do
not update the display until I manually resize the frame.

I start Emacs, use "C-x 5 2" a couple of times to get my usual three
frames. Only the last-created frame has "live" redisplay: I can switch
focus between the frames, but the others won't update. If I switch to a
frozen frame and do something like `find-file', I see the window title
change to "minibuffer", and commands are accepted correctly, but the
frame contents aren't updated.

If I resize a frame (toggle "floating") then that frame becomes the
"live" one, and the others freeze.

I use two main computers, both Arch linux. The misbehaving machine uses
X11 and i3 as the window manager. The other one uses Wayland and the
sway window manager, though Emacs still runs under Xwayland, and on this
machine everything works normally.

Let me know if I can provide more information...


In GNU Emacs 28.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.17.3)
 of 2020-10-23 built on clem
Repository revision: 46f5d2867cf73a845d582eeb8929ae51b78eae55
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12009000
System Description: Arch Linux

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

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

Major mode: Group

Minor modes in effect:
  gnus-topic-mode: t
  pyvenv-mode: t
  recentf-mode: t
  dired-async-mode: t
  gnus-undo-mode: t
  projectile-mode: t
  ivy-mode: t
  display-time-mode: t
  show-paren-mode: t
  savehist-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-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
  buffer-read-only: t
  line-number-mode: t

Features:
(shadow sort gnus-cite footnote orgalist mail-extr emacsbug utf-7 nnml
nnfolder nnmaildir epa-file gnutls network-stream gnus-topic gnus-delay
gnus-draft gnus-agent gnus-srvr gnus-score score-mode nnvirtual nntp
gnus-cache nndraft nnmh misearch multi-isearch autorevert filenotify
vc-git diff-mode autoinsert org-eldoc org-indent ol-eww eww xdg
url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus ol-docview
doc-view jka-compr image-mode exif ol-bibtex bibtex ol-bbdb ol-w3m
org-crypt init-modes yasnippet highlight-indentation flymake-proc
flymake warnings company-capf merlin-company company help-fns radix-tree
elpy elpy-rpc pyvenv eshell esh-cmd esh-ext esh-opt esh-proc esh-io
esh-arg esh-module esh-groups esh-util elpy-shell elpy-profile
elpy-django s elpy-refactor ido cus-edit cus-start cus-load recentf
tree-widget slime-fancy slime-trace-dialog slime-fontifying-fu
slime-package-fu slime-references slime-compiler-notes-tree
slime-scratch slime-presentations bridge slime-macrostep macrostep
slime-mdot-fu slime-enclosing-context slime-fuzzy slime-fancy-trace
slime-fancy-inspector slime-c-p-c slime-editing-commands slime-autodoc
slime-repl elp slime-parse slime paredit flyspell ispell visible-mark
lisp-mnt gud apropos etags fileloop xref project arc-mode archive-mode
pp hyperspec dired-async dired-aux ebdb-org ebdb-message sendmail
ebdb-gnorb ebdb-snarf ebdb-gnus nnselect gnus-msg ebdb-mua ebdb-com
ebdb-format ebdb-i18n-chn ebdb-i18n ebdb-i18n-basic ebdb inline
eieio-opt cl-extra speedbar ezimage dframe timezone gnus-icalendar
gnorb-registry gnus-registry registry eieio-base gnorb-gnus org-capture
org-attach gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum
shr kinsoku svg dom gnus-group gnus-undo nngnorb gnus-start gnus-dbus
gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int
gnus-range message dired dired-loaddefs rfc822 mml mml-sec epa epg
epg-config mailabbrev mailheader gnus-win nnir gnus wid-edit mm-decode
mm-bodies mm-encode gmm-utils gnorb gnorb-org gnorb-utils pcase nnheader
gnus-util rmail rmail-loaddefs mail-utils async-bytecomp async
pyim-basedict pyim pyim-probe xr rx pyim-common pyim-pymap popup
help-mode notifications dbus org-annotate derived merlin-cap merlin
caml-types caml-emacs crm cl vlf-setup init-my my-autoloads init-org
ob-sqlite ob-sql ob-gnuplot ob-org ob-ledger ob-plantuml ob-lisp
ob-latex ob-shell ob-python python ob-R calc-prog org-caldav icalendar
diary-lib diary-loaddefs org-id url-dav url-http url-auth mail-parse
rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm rmc
puny xml calc-units calc-ext calc calc-loaddefs calc-macs org-mobile
org-agenda org-refile ox-odt rng-loc rng-uri rng-parse rng-match rng-dt
rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util ox-latex
ox-icalendar ox-html table ox-ascii ox-publish ox org-element avl-tree
generator org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro
org-footnote org-src ob-comint org-pcomplete org-list org-faces
org-entities noutline outline org-version ob-emacs-lisp ob-core ob-eval
org-table ol org-keys org-compat advice org-macs org-loaddefs find-func
cal-menu calendar cal-loaddefs tramp-cache tramp-sh projectile grep
compile text-property-search ibuf-ext ibuffer ibuffer-loaddefs thingatpt
ivy flx delsel ivy-faces ivy-overlay colir color eieio-datadebug
data-debug time paren savehist tramp tramp-loaddefs trampver
tramp-integration files-x tramp-compat shell pcomplete comint ansi-color
ring parse-time iso8601 time-date ls-lisp format-spec server prose-mode
easy-mmode edmacro kmacro tex-site slime-autoloads w3m-load info package
easymenu browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib china-util 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 button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 1668948 132650)
 (symbols 48 50482 2)
 (strings 32 762105 17018)
 (string-bytes 1 35772086)
 (vectors 16 81412)
 (vector-slots 8 1447953 84970)
 (floats 8 494 261)
 (intervals 56 92788 0)
 (buffers 992 74))

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Fri, 23 Oct 2020 11:17:16 -0700
> 
> I rebuilt Emacs on one of my machines yesterday, and am seeing odd
> behavior (with emacs -Q): I use a tiling window manager, which
> fullscreens frames by default, and when I open multiple Emacs frames,
> only one of them redisplays correctly, the others stay "frozen" and do
> not update the display until I manually resize the frame.
> 
> I start Emacs, use "C-x 5 2" a couple of times to get my usual three
> frames. Only the last-created frame has "live" redisplay: I can switch
> focus between the frames, but the others won't update. If I switch to a
> frozen frame and do something like `find-file', I see the window title
> change to "minibuffer", and commands are accepted correctly, but the
> frame contents aren't updated.

Sounds like Emacs thinks those other frames are invisible or
iconified.  Emacs never redisplays such frames, for obvious reasons.

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eric Abrahamsen]

On 10/23/20 21:25 PM, Eli Zaretskii wrote:
>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Date: Fri, 23 Oct 2020 11:17:16 -0700
>> 
>> I rebuilt Emacs on one of my machines yesterday, and am seeing odd
>> behavior (with emacs -Q): I use a tiling window manager, which
>> fullscreens frames by default, and when I open multiple Emacs frames,
>> only one of them redisplays correctly, the others stay "frozen" and do
>> not update the display until I manually resize the frame.
>> 
>> I start Emacs, use "C-x 5 2" a couple of times to get my usual three
>> frames. Only the last-created frame has "live" redisplay: I can switch
>> focus between the frames, but the others won't update. If I switch to a
>> frozen frame and do something like `find-file', I see the window title
>> change to "minibuffer", and commands are accepted correctly, but the
>> frame contents aren't updated.
>
> Sounds like Emacs thinks those other frames are invisible or
> iconified.  Emacs never redisplays such frames, for obvious reasons.

Thanks for the clue. I get:

(mapcar (lambda (f) (frame-parameter f 'visibility)) (frame-list))
=> (icon icon t)df

Whichever frame I've forced to be "live" always gets t, and the others
become icons.

If I split the screen to show two frames side-by-side, they both become
visible.

I haven't changed anything in my window manager config, and the i3
package hasn't been updated since August. The only recent commit that
looks like it could be at all relevant is 2c0cd90083.

Hope this points the way further...

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: 44180@debbugs.gnu.org
> Date: Fri, 23 Oct 2020 12:07:33 -0700
> 
> > Sounds like Emacs thinks those other frames are invisible or
> > iconified.  Emacs never redisplays such frames, for obvious reasons.
> 
> Thanks for the clue. I get:
> 
> (mapcar (lambda (f) (frame-parameter f 'visibility)) (frame-list))
> => (icon icon t)df
> 
> Whichever frame I've forced to be "live" always gets t, and the others
> become icons.

What do you mean by "become icons"?  Are they visible or aren't they?

> I haven't changed anything in my window manager config, and the i3
> package hasn't been updated since August. The only recent commit that
> looks like it could be at all relevant is 2c0cd90083.

And if you revert that change, does the problem go away?

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eric Abrahamsen]

On 10/23/20 22:38 PM, Eli Zaretskii wrote:
>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Cc: 44180@debbugs.gnu.org
>> Date: Fri, 23 Oct 2020 12:07:33 -0700
>> 
>> > Sounds like Emacs thinks those other frames are invisible or
>> > iconified.  Emacs never redisplays such frames, for obvious reasons.
>> 
>> Thanks for the clue. I get:
>> 
>> (mapcar (lambda (f) (frame-parameter f 'visibility)) (frame-list))
>> => (icon icon t)df
>> 
>> Whichever frame I've forced to be "live" always gets t, and the others
>> become icons.
>
> What do you mean by "become icons"?  Are they visible or aren't they?

I just meant that their 'visibility frame-parameter became 'icon. Their
"real" visibility is the same as always -- the two non-focused frames
are visible only as stacked title bars above the currently focused frame.

>> I haven't changed anything in my window manager config, and the i3
>> package hasn't been updated since August. The only recent commit that
>> looks like it could be at all relevant is 2c0cd90083.
>
> And if you revert that change, does the problem go away?

Yes it does!

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[martin rudalics]

I just meant that their 'visibility frame-parameter became 'icon. Their
 > "real" visibility is the same as always -- the two non-focused frames
 > are visible only as stacked title bars above the currently focused frame.

Can you please describe this in more detail.  As I understand it, your
initial frame looks as usual until you do C-x 5 2.  At that moment, the
initial frame becomes non-focused and appears as a stacked title bar
while the new frame becomes focused and appears as expected.  Is that
right?  Then how does the "fullscreen frames by default" fit into this
picture and how does a tiling manager use stacking?

 >>> I haven't changed anything in my window manager config, and the i3
 >>> package hasn't been updated since August. The only recent commit that
 >>> looks like it could be at all relevant is 2c0cd90083.
 >>
 >> And if you revert that change, does the problem go away?
 >
 > Yes it does!

Maybe we need an option for 2c0cd90083.  Maybe we also should just
wait.  I'd expect a few more of such reports to drop in.

martin

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: 44180@debbugs.gnu.org
> Date: Fri, 23 Oct 2020 14:07:00 -0700
> 
> >> (mapcar (lambda (f) (frame-parameter f 'visibility)) (frame-list))
> >> => (icon icon t)df
> >> 
> >> Whichever frame I've forced to be "live" always gets t, and the others
> >> become icons.
> >
> > What do you mean by "become icons"?  Are they visible or aren't they?
> 
> I just meant that their 'visibility frame-parameter became 'icon. Their
> "real" visibility is the same as always -- the two non-focused frames
> are visible only as stacked title bars above the currently focused frame.

Isn't that a bug that needs to be fixed, regardless?  Emacs will not
handle iconified frames as it does visible frames, so sooner or later
problems will appear due to that.

> >> I haven't changed anything in my window manager config, and the i3
> >> package hasn't been updated since August. The only recent commit that
> >> looks like it could be at all relevant is 2c0cd90083.
> >
> > And if you revert that change, does the problem go away?
> 
> Yes it does!

Then I guess we will have to revert at least part of that change.

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eli Zaretskii]

> Cc: 44180@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Sat, 24 Oct 2020 08:55:48 +0200
> 
>  >> And if you revert that change, does the problem go away?
>  >
>  > Yes it does!
> 
> Maybe we need an option for 2c0cd90083.  Maybe we also should just
> wait.  I'd expect a few more of such reports to drop in.

(Adding J. Scott to the addressees.)

What about ignoring these events only if the size is 1x1, which is
definitely bogus?  Would that work in the VcXsrv case?

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eric Abrahamsen]

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


On 10/24/20 08:55 AM, martin rudalics wrote:
> I just meant that their 'visibility frame-parameter became 'icon. Their
>> "real" visibility is the same as always -- the two non-focused frames
>> are visible only as stacked title bars above the currently focused frame.
>
> Can you please describe this in more detail.  As I understand it, your
> initial frame looks as usual until you do C-x 5 2.  At that moment, the
> initial frame becomes non-focused and appears as a stacked title bar
> while the new frame becomes focused and appears as expected.  Is that
> right?  Then how does the "fullscreen frames by default" fit into this
> picture and how does a tiling manager use stacking?

Sorry if this wasn't clear. The window manager can display multiple
windows (our frames) tiled into some sort of grid, in which case
everything behaves correctly, or it can allow one of the windows to take
up the full workspace, and other windows are only visible as a sort of
window title bar, either tabbed along the top, or stacked along the top.
I'm attaching a screenshot, that's stacked.

My understanding is that this is *not* equivalent to X11's
iconification or minification, where the window disappears and shows up
as a icon in some notification area. i3 does have a notification bar,
but I wouldn't know how to send a window there. In the screenshotted
situation, i3 provides keybindings for switching focus between the
stacked windows, but I believe in X11 terms, all three windows are meant
to be visible, you're just switching which one is "foremost".

I've got i3 set up to use stacking by default, meaning that as new
windows are created they are added to the stack and displayed on top.
You can also have them tabbed or split by default.

I hope that makes sense. I'd be happy to try to contact an i3 person and
ask them exactly what's happening, in X11 terms.

Thanks,
Eric



[-- Attachment #2: 20201024_13h14m00s_grim.png --]
[-- Type: image/png, Size: 196474 bytes --]

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  44180@debbugs.gnu.org
> Date: Sat, 24 Oct 2020 13:19:45 -0700
> 
> Sorry if this wasn't clear. The window manager can display multiple
> windows (our frames) tiled into some sort of grid, in which case
> everything behaves correctly, or it can allow one of the windows to take
> up the full workspace, and other windows are only visible as a sort of
> window title bar, either tabbed along the top, or stacked along the top.
> I'm attaching a screenshot, that's stacked.

Since the other frames are not really visible, treating them as
iconified makes some sense.  But then I don't understand your original
report: you said these frames are not updated, but since they are
obscured, what does "updated" mean for them?

IOW, I'm now confused regarding the original report of the problem you
have.  I guess we need to start from the beginning now, so I'm asking
you to describe in more detail what doesn't work in this situation.

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eric Abrahamsen]

On 10/25/20 17:08 PM, Eli Zaretskii wrote:
>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  44180@debbugs.gnu.org
>> Date: Sat, 24 Oct 2020 13:19:45 -0700
>> 
>> Sorry if this wasn't clear. The window manager can display multiple
>> windows (our frames) tiled into some sort of grid, in which case
>> everything behaves correctly, or it can allow one of the windows to take
>> up the full workspace, and other windows are only visible as a sort of
>> window title bar, either tabbed along the top, or stacked along the top.
>> I'm attaching a screenshot, that's stacked.
>
> Since the other frames are not really visible, treating them as
> iconified makes some sense.  But then I don't understand your original
> report: you said these frames are not updated, but since they are
> obscured, what does "updated" mean for them?
>
> IOW, I'm now confused regarding the original report of the problem you
> have.  I guess we need to start from the beginning now, so I'm asking
> you to describe in more detail what doesn't work in this situation.

The problem is that switching focus between windows (frames) does not
update which window is "live". The most-recently created, or
most-recently resized, window is always the live one. If I switch focus
to one of the other frames, it doesn't update, and I need to move it
around somehow in order to make it live. Then the other frames go dead.

Before the breakage, it's possible that the non-visible frames were not
updated while they remained invisible, and I simply never knew because
I couldn't see them. Now they stay un-updated until I manipulate the
size of the window somehow.

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: rudalics@gmx.at,  44180@debbugs.gnu.org
> Date: Sun, 25 Oct 2020 09:01:20 -0700
> 
> The problem is that switching focus between windows (frames) does not
> update which window is "live". The most-recently created, or
> most-recently resized, window is always the live one. If I switch focus
> to one of the other frames, it doesn't update, and I need to move it
> around somehow in order to make it live. Then the other frames go dead.
> 
> Before the breakage, it's possible that the non-visible frames were not
> updated while they remained invisible, and I simply never knew because
> I couldn't see them. Now they stay un-updated until I manipulate the
> size of the window somehow.

That seems to suggest that we don't trigger expose_frame calls anymore
for the frames that become un-fontified?

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Sascha Sadeghian]

Eli Zaretskii <eliz@gnu.org> wrote:
> Since the other frames are not really visible, treating them as
> iconified makes some sense.  But then I don't understand your original
> report: you said these frames are not updated, but since they are
> obscured, what does "updated" mean for them?

I am seeing similar behaviour with the i3 window manager.

Let’s say we start with an Emacs GTK window and an xterm window side by
side, so that each has 50% of the total screen width ("split" mode in
i3). If I switch to "tabbed" mode now and select the Emacs tab, the
Emacs frame is unresponsive, and its contents are not redrawn any more.

This didn’t happen before 2c0cd90083.

Here is a quick demo with emacs -Q:

  https://webterm.io/bug-gnu-emacs/44180-working.webm
  https://webterm.io/bug-gnu-emacs/44180-broken.webm

The bug can be reproduced with a single frame.

The confusing part is probably that for this frozen frame, keyboard
input is still working, so buffers can be edited, while the edits are
only visible in other, non-frozen frames (for example, a second
emacsclient frame showing the same buffers). The GTK menu and toolbar
are also not affected.

Hope this helps!

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Cc: rudalics@gmx.at,  44180@debbugs.gnu.org
>> Date: Sun, 25 Oct 2020 09:01:20 -0700
>> 
>> The problem is that switching focus between windows (frames) does not
>> update which window is "live". The most-recently created, or
>> most-recently resized, window is always the live one. If I switch focus
>> to one of the other frames, it doesn't update, and I need to move it
>> around somehow in order to make it live. Then the other frames go dead.
>> 
>> Before the breakage, it's possible that the non-visible frames were not
>> updated while they remained invisible, and I simply never knew because
>> I couldn't see them. Now they stay un-updated until I manipulate the
>> size of the window somehow.
>
> That seems to suggest that we don't trigger expose_frame calls anymore
> for the frames that become un-fontified?

I wouldn't know, but that certainly sounds likely. I'd be happy to try
contacting someone at i3, if that would be helpful, or to try fiddling
with the display code.

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: 44180@debbugs.gnu.org
> Date: Sun, 25 Oct 2020 09:28:09 -0700
> 
> >> Before the breakage, it's possible that the non-visible frames were not
> >> updated while they remained invisible, and I simply never knew because
> >> I couldn't see them. Now they stay un-updated until I manipulate the
> >> size of the window somehow.
> >
> > That seems to suggest that we don't trigger expose_frame calls anymore
> > for the frames that become un-fontified?
> 
> I wouldn't know, but that certainly sounds likely. I'd be happy to try
> contacting someone at i3, if that would be helpful, or to try fiddling
> with the display code.

What would help is if you put a breakpoint at expose_frame, and see
how it is called when the changes made by the offending commit are
reverted.  Please show which X event triggers that and with what
parameters.  Then do the same with the offending changes in place, and
try to figure out why the expose event doesn't get triggered.

Armed with that info, we could try finding a way of having the cake
and eating it, too.

TIA

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eli Zaretskii]

> Date: Sun, 25 Oct 2020 17:26:18 +0100
> From: Sascha Sadeghian <sadeghian@acm.org>
> Cc: Eric Abrahamsen <eric@ericabrahamsen.net>, 44180@debbugs.gnu.org
> 
> Let’s say we start with an Emacs GTK window and an xterm window side by
> side, so that each has 50% of the total screen width ("split" mode in
> i3). If I switch to "tabbed" mode now and select the Emacs tab, the
> Emacs frame is unresponsive, and its contents are not redrawn any more.
> 
> This didn’t happen before 2c0cd90083.
> 
> Here is a quick demo with emacs -Q:
> 
>   https://webterm.io/bug-gnu-emacs/44180-working.webm
>   https://webterm.io/bug-gnu-emacs/44180-broken.webm
> 
> The bug can be reproduced with a single frame.
> 
> The confusing part is probably that for this frozen frame, keyboard
> input is still working, so buffers can be edited, while the edits are
> only visible in other, non-frozen frames (for example, a second
> emacsclient frame showing the same buffers). The GTK menu and toolbar
> are also not affected.

This is actually not confusing at all, it is entirely expected.

> Hope this helps!

I've just explained to Eric which information would be helpful to make
some progress here.  If you can help collecting that information, it
will be really appreciated.

Thanks.

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Cc: 44180@debbugs.gnu.org
>> Date: Sun, 25 Oct 2020 09:28:09 -0700
>> 
>> >> Before the breakage, it's possible that the non-visible frames were not
>> >> updated while they remained invisible, and I simply never knew because
>> >> I couldn't see them. Now they stay un-updated until I manipulate the
>> >> size of the window somehow.
>> >
>> > That seems to suggest that we don't trigger expose_frame calls anymore
>> > for the frames that become un-fontified?
>> 
>> I wouldn't know, but that certainly sounds likely. I'd be happy to try
>> contacting someone at i3, if that would be helpful, or to try fiddling
>> with the display code.
>
> What would help is if you put a breakpoint at expose_frame, and see
> how it is called when the changes made by the offending commit are
> reverted.  Please show which X event triggers that and with what
> parameters.  Then do the same with the offending changes in place, and
> try to figure out why the expose event doesn't get triggered.
>
> Armed with that info, we could try finding a way of having the cake
> and eating it, too.

Okay, got it. I won't have access to the misbehaving machine until
tomorrow, but will do this then. Maybe Sascha will beat me to it.

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[martin rudalics]

 > The problem is that switching focus between windows (frames) does not
 > update which window is "live". The most-recently created, or
 > most-recently resized, window is always the live one. If I switch focus
 > to one of the other frames, it doesn't update, and I need to move it
 > around somehow in order to make it live. Then the other frames go dead.
 >
 > Before the breakage, it's possible that the non-visible frames were not
 > updated while they remained invisible, and I simply never knew because
 > I couldn't see them. Now they stay un-updated until I manipulate the
 > size of the window somehow.

Do you get the corresponding focus events (whatever they are now) when
you make another frame the fullscreen one?  If so, we should probably
redraw the frame in that case.

martin

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eric Abrahamsen]

martin rudalics <rudalics@gmx.at> writes:

>> The problem is that switching focus between windows (frames) does not
>> update which window is "live". The most-recently created, or
>> most-recently resized, window is always the live one. If I switch focus
>> to one of the other frames, it doesn't update, and I need to move it
>> around somehow in order to make it live. Then the other frames go dead.
>>
>> Before the breakage, it's possible that the non-visible frames were not
>> updated while they remained invisible, and I simply never knew because
>> I couldn't see them. Now they stay un-updated until I manipulate the
>> size of the window somehow.
>
> Do you get the corresponding focus events (whatever they are now) when
> you make another frame the fullscreen one?  If so, we should probably
> redraw the frame in that case.

I'm still not at the offending computer, but I think there's a high
likelihood of confusing myself with conflicting terminology here so,
just to be clear: this isn't proper fullscreening in the X11 sense. i3
also does that, but I hardly ever use it since the stacked layout is
close enough to full screen. In X11 terms I think all that's happening
is switching of focus between windows, it's just that i3's layout means
that the unfocused windows are always completely obscured. For some
reason Emacs now thinks that a window being obscured means that it's now
an icon. Switching focus back to that window does not un-iconify it.

Anyway, more later in the day...

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[martin rudalics]

 >> Do you get the corresponding focus events (whatever they are now) when
 >> you make another frame the fullscreen one?  If so, we should probably
 >> redraw the frame in that case.
 >
 > I'm still not at the offending computer, but I think there's a high
 > likelihood of confusing myself with conflicting terminology here so,
 > just to be clear: this isn't proper fullscreening in the X11 sense.

I didn't expect it to be but thanks for confirming.

 > i3
 > also does that, but I hardly ever use it since the stacked layout is
 > close enough to full screen. In X11 terms I think all that's happening
 > is switching of focus between windows, it's just that i3's layout means
 > that the unfocused windows are always completely obscured. For some
 > reason Emacs now thinks that a window being obscured means that it's now
 > an icon. Switching focus back to that window does not un-iconify it.

Always keep in mind that Emacs has no idea about whether and how a
window has been iconified or focused.  It just waits for the
corresponding information from the window manager, believes what the
latter tells and acts (redrawing a frame, for example) accordingly.

 > Anyway, more later in the day...

martin

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eric Abrahamsen]

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


On 10/27/20 10:08 AM, martin rudalics wrote:
>>> Do you get the corresponding focus events (whatever they are now) when
>>> you make another frame the fullscreen one?  If so, we should probably
>>> redraw the frame in that case.
>>
>> I'm still not at the offending computer, but I think there's a high
>> likelihood of confusing myself with conflicting terminology here so,
>> just to be clear: this isn't proper fullscreening in the X11 sense.
>
> I didn't expect it to be but thanks for confirming.
>
>> i3
>> also does that, but I hardly ever use it since the stacked layout is
>> close enough to full screen. In X11 terms I think all that's happening
>> is switching of focus between windows, it's just that i3's layout means
>> that the unfocused windows are always completely obscured. For some
>> reason Emacs now thinks that a window being obscured means that it's now
>> an icon. Switching focus back to that window does not un-iconify it.
>
> Always keep in mind that Emacs has no idea about whether and how a
> window has been iconified or focused.  It just waits for the
> corresponding information from the window manager, believes what the
> latter tells and acts (redrawing a frame, for example) accordingly.

Okay, thanks.

I think I'm going to need more help here, though. I have built master
with optimizations off, I start GDB in a controlling emacs, set a
breakpoint at xdisp.c:34381 at the beginning of expose_frame, and then
"run -Q".

That pops up a new frame, and we hit the breakpoint. I run "bt" and have
attached the resulting backtrace. Something tells me you need more
information than this, though. I went up a frame, to handle_one_xevent,
where there are a bunch of local values I can print, but the values of
dpyinfo and event are enormous structures.

What variables exactly would you need to see?

Again, this is on misbehaving master. Once I know exactly what you need
I'll do the same for a build with the commit reverted.

Thanks,
Eric


[-- Attachment #2: master.txt --]
[-- Type: text/plain, Size: 3618 bytes --]

#0  expose_frame (f=0x555556313f00, x=1900, y=1030, w=16, h=34) at xdisp.c:34381
#1  0x00005555556f2711 in handle_one_xevent (dpyinfo=0x55555604c400, event=0x7fffffffcd90, finish=0x555555e1f6fc <current_finish>, hold_quit=0x7fffffffd0a0) at xterm.c:8243
#2  0x00005555556f13dd in event_handler_gdk (gxev=0x7fffffffcd90, ev=0x555555fe8ca0, data=0x0) at xterm.c:7768
#3  0x00007ffff75c654f in  () at /usr/lib/libgdk-3.so.0
#4  0x00007ffff75ca10b in  () at /usr/lib/libgdk-3.so.0
#5  0x00007ffff756e15b in gdk_display_get_event () at /usr/lib/libgdk-3.so.0
#6  0x00007ffff75c9e44 in  () at /usr/lib/libgdk-3.so.0
#7  0x00007ffff6f8d914 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#8  0x00007ffff6fe17d1 in  () at /usr/lib/libglib-2.0.so.0
#9  0x00007ffff6f8c121 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#10 0x00007ffff781d597 in gtk_main_iteration () at /usr/lib/libgtk-3.so.0
#11 0x00005555556f5491 in XTread_socket (terminal=0x555555f94dd8, hold_quit=0x7fffffffd0a0) at xterm.c:9395
#12 0x000055555574f92d in gobble_input () at keyboard.c:6890
#13 0x000055555574ff5b in handle_async_input () at keyboard.c:7127
#14 0x000055555574ff7a in process_pending_signals () at keyboard.c:7141
#15 0x000055555581e182 in maybe_quit () at eval.c:1549
#16 0x0000555555829f94 in list_length (list=XIL(0x555555f2dc63)) at fns.c:98
#17 0x000055555582a106 in Flength (sequence=XIL(0x555556832353)) at fns.c:126
#18 0x000055555582baf9 in concat (nargs=1, args=0x7fffffffd318, target_type=Lisp_Cons, last_special=false) at fns.c:666
#19 0x000055555582b8d6 in Fcopy_sequence (arg=XIL(0x555556832353)) at fns.c:598
#20 0x00005555557492b0 in timer_check () at keyboard.c:4398
#21 0x0000555555746f69 in readable_events (flags=1) at keyboard.c:3405
#22 0x000055555574f743 in get_input_pending (flags=1) at keyboard.c:6805
#23 0x00005555557591e4 in detect_input_pending_run_timers (do_display=true) at keyboard.c:10366
#24 0x0000555555891fa5 in wait_reading_process_output (time_limit=0, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at process.c:5702
#25 0x0000555555747f1b in kbd_buffer_get_event (kbp=0x7fffffffd920, used_mouse_menu=0x7fffffffdf2d, end_time=0x0) at keyboard.c:3874
#26 0x0000555555742678 in read_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffdd30, used_mouse_menu=0x7fffffffdf2d) at keyboard.c:2160
#27 0x0000555555742a88 in read_decoded_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffdd30, prev_event=XIL(0), used_mouse_menu=0x7fffffffdf2d) at keyboard.c:2224
#28 0x0000555555744cd2 in read_char (commandflag=1, map=XIL(0x5555568323b3), prev_event=XIL(0), used_mouse_menu=0x7fffffffdf2d, end_time=0x0) at keyboard.c:2834
#29 0x0000555555757125 in read_key_sequence (keybuf=0x7fffffffe110, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9552
#30 0x000055555573fd76 in command_loop_1 () at keyboard.c:1354
#31 0x000055555581db25 in internal_condition_case (bfun=0x55555573f8dc <command_loop_1>, handlers=XIL(0x90), hfun=0x55555573eed0 <cmd_error>) at eval.c:1359
#32 0x000055555573f4c5 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1095
#33 0x000055555581cf79 in internal_catch (tag=XIL(0xd710), func=0x55555573f498 <command_loop_2>, arg=XIL(0)) at eval.c:1120
#34 0x000055555573f464 in command_loop () at keyboard.c:1074
#35 0x000055555573e9b9 in recursive_edit_1 () at keyboard.c:718
#36 0x000055555573ebb0 in Frecursive_edit () at keyboard.c:790
#37 0x000055555573a984 in main (argc=2, argv=0x7fffffffe598) at emacs.c:2047

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  44180@debbugs.gnu.org
> Date: Tue, 27 Oct 2020 11:11:26 -0700
> 
> I think I'm going to need more help here, though. I have built master
> with optimizations off, I start GDB in a controlling emacs, set a
> breakpoint at xdisp.c:34381 at the beginning of expose_frame, and then
> "run -Q".
> 
> That pops up a new frame, and we hit the breakpoint.

That's the initial frame, isn't it?  If so, this is not the frame we
want, we want a frame that was obscured and then gets the focus.

To save yourself from a lot of unwanted breakpoint hits, I suggest
this paradigm:

 $ gdb ./emacs
 (gdb) break Frecenter
 (gdb) r -Q

Inside Emacs:

  M-x blink-cursor-mode RET
  M-x global-eldoc-mode RET

Now create one or more other frames and make them obscured
("iconified").  Now type C-l -- this will hit the breakpoint in
Frecenter, and GDB will kick in.  Then set a breakpoint in
expose_frame and type "continue".  Finally, switch to a frame that was
obscured: does the breakpoint in expose_frame break, and if so, is
Emacs told to expose the correct frame, the one that was obscured and
is going to become visible?  If it's the correct frame, show the
backtrace.

Then do all this again, but after reverting the change which causes
the problem.  By comparing the backtraces and the behavior, we might
begin to understand how this change causes the problem in your case.

Thanks.

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eric Abrahamsen]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  44180@debbugs.gnu.org
>> Date: Tue, 27 Oct 2020 11:11:26 -0700
>> 
>> I think I'm going to need more help here, though. I have built master
>> with optimizations off, I start GDB in a controlling emacs, set a
>> breakpoint at xdisp.c:34381 at the beginning of expose_frame, and then
>> "run -Q".
>> 
>> That pops up a new frame, and we hit the breakpoint.
>
> That's the initial frame, isn't it?  If so, this is not the frame we
> want, we want a frame that was obscured and then gets the focus.
>
> To save yourself from a lot of unwanted breakpoint hits, I suggest
> this paradigm:
>
>  $ gdb ./emacs
>  (gdb) break Frecenter
>  (gdb) r -Q
>
> Inside Emacs:
>
>   M-x blink-cursor-mode RET
>   M-x global-eldoc-mode RET
>
> Now create one or more other frames and make them obscured
> ("iconified").  Now type C-l -- this will hit the breakpoint in
> Frecenter, and GDB will kick in.  Then set a breakpoint in
> expose_frame and type "continue".  Finally, switch to a frame that was
> obscured: does the breakpoint in expose_frame break, and if so, is
> Emacs told to expose the correct frame, the one that was obscured and
> is going to become visible?  If it's the correct frame, show the
> backtrace.
>
> Then do all this again, but after reverting the change which causes
> the problem.  By comparing the backtraces and the behavior, we might
> begin to understand how this change causes the problem in your case.

Okay, hope this is helpful. I start in a workspace with only the
terminal, do the gdb dance, and when I run "r -Q" the first frame
appears, in stacked mode, taking up the whole screen. I create a second
frame: now i3 has a vertical stack of three windows: terminal, emacs1
and emacs2 -- emacs2 is focused.

I shut off blink cursor and global eldoc, note the frame addresses, then
move focus "wrap-around" style down and back around to the terminal, so
the emacs1 window (which is the "stuck" one in master) never receives
focus (that might not be important).

Back in the terminal I pause execution, set the expose_frame breakpoint,
turn on logging, and continue. Then move focus down to emacs1, back up
to the terminal, see the breakpoint has triggered, get a backtrace, and
confirm that the frame in question is indeed emacs1.

I did that exact routine in both master and a "revert" branch, with the
commit reverted.

Fingers crossed!


[-- Attachment #2: master.txt --]
[-- Type: text/plain, Size: 5048 bytes --]

#0  expose_frame (f=0x555556317630, x=0, y=1042, w=1900, h=10) at xdisp.c:34381
#1  0x00005555556f2711 in handle_one_xevent (dpyinfo=0x5555560a2fe0, event=0x7fffffffd420, finish=0x555555e1f6fc <current_finish>, hold_quit=0x7fffffffd730) at xterm.c:8243
#2  0x00005555556f13dd in event_handler_gdk (gxev=0x7fffffffd420, ev=0x555555fecde0, data=0x0) at xterm.c:7768
#3  0x00007ffff75c654f in  () at /usr/lib/libgdk-3.so.0
#4  0x00007ffff75ca10b in  () at /usr/lib/libgdk-3.so.0
#5  0x00007ffff756e15b in gdk_display_get_event () at /usr/lib/libgdk-3.so.0
#6  0x00007ffff75c9e44 in  () at /usr/lib/libgdk-3.so.0
#7  0x00007ffff6f8d914 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#8  0x00007ffff6fe17d1 in  () at /usr/lib/libglib-2.0.so.0
#9  0x00007ffff6f8c121 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#10 0x00007ffff781d597 in gtk_main_iteration () at /usr/lib/libgtk-3.so.0
#11 0x00005555556f5491 in XTread_socket (terminal=0x555555f94d38, hold_quit=0x7fffffffd730) at xterm.c:9395
#12 0x000055555574f92d in gobble_input () at keyboard.c:6890
#13 0x000055555574ff5b in handle_async_input () at keyboard.c:7127
#14 0x000055555574ff7a in process_pending_signals () at keyboard.c:7141
#15 0x0000555555890bab in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at process.c:5248
#16 0x00005555555a857f in sit_for (timeout=make_fixnum(30), reading=true, display_option=1) at dispnew.c:6056
#17 0x0000555555744631 in read_char (commandflag=1, map=XIL(0x555555f8dbb3), prev_event=XIL(0), used_mouse_menu=0x7fffffffdf5d, end_time=0x0) at keyboard.c:2742
#18 0x0000555555757125 in read_key_sequence (keybuf=0x7fffffffe140, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9552
#19 0x000055555573fd76 in command_loop_1 () at keyboard.c:1354
#20 0x000055555581db25 in internal_condition_case (bfun=0x55555573f8dc <command_loop_1>, handlers=XIL(0x90), hfun=0x55555573eed0 <cmd_error>) at eval.c:1359
#21 0x000055555573f4c5 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1095
#22 0x000055555581cf79 in internal_catch (tag=XIL(0xd710), func=0x55555573f498 <command_loop_2>, arg=XIL(0)) at eval.c:1120
#23 0x000055555573f464 in command_loop () at keyboard.c:1074
#24 0x000055555573e9b9 in recursive_edit_1 () at keyboard.c:718
#25 0x000055555573ebb0 in Frecursive_edit () at keyboard.c:790
#26 0x000055555573a984 in main (argc=2, argv=0x7fffffffe5c8) at emacs.c:2047
Continuing.

Thread 1 "emacs" hit Breakpoint 3, expose_frame (f=0x555556317630, x=0, y=1052, w=1916, h=12) at xdisp.c:34381
34381	{
Continuing.

Thread 1 "emacs" received signal SIGTSTP, Stopped (user).
0x00007ffff5af2c96 in pselect () from /usr/lib/libc.so.6
#0  0x00007ffff5af2c96 in pselect () at /usr/lib/libc.so.6
#1  0x00005555558d3322 in really_call_select (arg=0x7fffffffd170) at thread.c:592
#2  0x00005555557e1ff5 in flush_stack_call_func1 (func=0x5555558d325b <really_call_select>, arg=0x7fffffffd170) at alloc.c:5066
#3  0x00005555558d2620 in flush_stack_call_func (func=0x5555558d325b <really_call_select>, arg=0x7fffffffd170) at lisp.h:3791
#4  0x00005555558d341f in thread_select (func=0x7ffff5af2bd0 <pselect>, max_fds=7, rfds=0x7fffffffd280, wfds=0x7fffffffd300, efds=0x0, timeout=0x7fffffffd8d0, sigmask=0x0) at thread.c:624
#5  0x0000555555909f8a in xg_select (fds_lim=7, rfds=0x7fffffffd940, wfds=0x7fffffffd9c0, efds=0x0, timeout=0x7fffffffd8d0, sigmask=0x0) at xgselect.c:131
#6  0x0000555555891bdc in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at process.c:5604
#7  0x00005555555a857f in sit_for (timeout=make_fixnum(30), reading=true, display_option=1) at dispnew.c:6056
#8  0x0000555555744631 in read_char (commandflag=1, map=XIL(0x555555f8dbb3), prev_event=XIL(0), used_mouse_menu=0x7fffffffdf5d, end_time=0x0) at keyboard.c:2742
#9  0x0000555555757125 in read_key_sequence (keybuf=0x7fffffffe140, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9552
#10 0x000055555573fd76 in command_loop_1 () at keyboard.c:1354
#11 0x000055555581db25 in internal_condition_case (bfun=0x55555573f8dc <command_loop_1>, handlers=XIL(0x90), hfun=0x55555573eed0 <cmd_error>) at eval.c:1359
#12 0x000055555573f4c5 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1095
#13 0x000055555581cf79 in internal_catch (tag=XIL(0xd710), func=0x55555573f498 <command_loop_2>, arg=XIL(0)) at eval.c:1120
#14 0x000055555573f464 in command_loop () at keyboard.c:1074
#15 0x000055555573e9b9 in recursive_edit_1 () at keyboard.c:718
#16 0x000055555573ebb0 in Frecursive_edit () at keyboard.c:790
#17 0x000055555573a984 in main (argc=2, argv=0x7fffffffe5c8) at emacs.c:2047
Continuing.
[Thread 0x7ffff1132640 (LWP 49694) exited]
[Thread 0x7ffff2cf3fc0 (LWP 49690) exited]
[Inferior 1 (process 49690) exited normally]

[-- Attachment #3: revert.txt --]
[-- Type: text/plain, Size: 5520 bytes --]

#0  0x00007ffff5af2c96 in pselect () at /usr/lib/libc.so.6
#1  0x000055555576b78c in really_call_select (arg=0x7fffffffcf70) at thread.c:592
#2  0x000055555576c56f in flush_stack_call_func (arg=0x7fffffffcf70, func=0x55555576b720 <really_call_select>) at lisp.h:3791
#3  thread_select (func=<optimized out>, max_fds=max_fds@entry=7, rfds=rfds@entry=0x7fffffffd070, wfds=wfds@entry=0x7fffffffd0f0, efds=efds@entry=0x0, timeout=timeout@entry=0x7fffffffd6a0, sigmask=0x0)
    at thread.c:624
#4  0x0000555555788ffb in xg_select (fds_lim=7, rfds=rfds@entry=0x7fffffffd7b0, wfds=wfds@entry=0x7fffffffd830, efds=efds@entry=0x0, timeout=timeout@entry=0x7fffffffd6a0, sigmask=sigmask@entry=0x0)
    at xgselect.c:131
#5  0x0000555555749dcd in wait_reading_process_output
    (time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, wait_for_cell=wait_for_cell@entry=XIL(0), wait_proc=wait_proc@entry=0x0, just_wait_proc=0)
    at process.c:5604
#6  0x00005555555ab1ff in sit_for (timeout=timeout@entry=make_fixnum(30), reading=reading@entry=true, display_option=display_option@entry=1) at lisp.h:1007
#7  0x000055555569431f in read_char (commandflag=1, map=XIL(0x55555613fad3), prev_event=XIL(0), used_mouse_menu=0x7fffffffe04b, end_time=0x0) at lisp.h:1122
#8  0x0000555555694d44 in read_key_sequence (keybuf=<optimized out>, prompt=XIL(0), dont_downcase_last=<optimized out>, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<optimized out>)
    at keyboard.c:9552
#9  0x00005555556966cc in command_loop_1 () at lisp.h:1007
#10 0x0000555555703167 in internal_condition_case (bfun=bfun@entry=0x5555556964e0 <command_loop_1>, handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x55555568cc10 <cmd_error>) at eval.c:1359
#11 0x0000555555687194 in command_loop_2 (ignore=ignore@entry=XIL(0)) at lisp.h:1007
#12 0x00005555557030c1 in internal_catch (tag=tag@entry=XIL(0xd710), func=func@entry=0x555555687170 <command_loop_2>, arg=arg@entry=XIL(0)) at eval.c:1120
#13 0x000055555568713b in command_loop () at lisp.h:1007
#14 0x000055555568c826 in recursive_edit_1 () at keyboard.c:718
#15 0x000055555568cb52 in Frecursive_edit () at keyboard.c:790
#16 0x00005555555a0fcc in main (argc=2, argv=<optimized out>) at emacs.c:2047
Continuing.

Thread 1 "emacs" hit Breakpoint 3, expose_frame (f=0x55555604ae20, x=0, y=1042, w=1916, h=22) at xdisp.c:34381
34381	{
#0  expose_frame (f=0x55555604ae20, x=0, y=1042, w=1916, h=22) at xdisp.c:34381
#1  0x0000555555661b40 in handle_one_xevent (dpyinfo=<optimized out>, event=0x7fffffffd270, finish=0x555555b68ab0 <current_finish>, hold_quit=<optimized out>) at xterm.c:8243
#2  0x0000555555663078 in event_handler_gdk (gxev=0x7fffffffd270, ev=<optimized out>, data=<optimized out>) at xterm.c:7767
#3  0x00007ffff75c654f in  () at /usr/lib/libgdk-3.so.0
#4  0x00007ffff75ca10b in  () at /usr/lib/libgdk-3.so.0
#5  0x00007ffff756e15b in gdk_display_get_event () at /usr/lib/libgdk-3.so.0
#6  0x00007ffff75c9e44 in  () at /usr/lib/libgdk-3.so.0
#7  0x00007ffff6f8d914 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#8  0x00007ffff6fe17d1 in  () at /usr/lib/libglib-2.0.so.0
#9  0x00007ffff6f8c121 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#10 0x00007ffff781d597 in gtk_main_iteration () at /usr/lib/libgtk-3.so.0
#11 0x0000555555655df3 in XTread_socket (terminal=<optimized out>, hold_quit=0x7fffffffd530) at xterm.c:9394
#12 0x000055555568e552 in gobble_input () at keyboard.c:6890
#13 0x000055555568eb35 in handle_async_input () at keyboard.c:7127
#14 process_pending_signals () at keyboard.c:7141
#15 0x0000555555749e1d in wait_reading_process_output
    (time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, wait_for_cell=wait_for_cell@entry=XIL(0), wait_proc=wait_proc@entry=0x0, just_wait_proc=0)
    at process.c:5248
#16 0x00005555555ab1ff in sit_for (timeout=timeout@entry=make_fixnum(30), reading=reading@entry=true, display_option=display_option@entry=1) at lisp.h:1007
#17 0x000055555569431f in read_char (commandflag=1, map=XIL(0x555555c60ed3), prev_event=XIL(0), used_mouse_menu=0x7fffffffe04b, end_time=0x0) at lisp.h:1122
#18 0x0000555555694d44 in read_key_sequence (keybuf=<optimized out>, prompt=XIL(0), dont_downcase_last=<optimized out>, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<optimized out>)
    at keyboard.c:9552
#19 0x00005555556966cc in command_loop_1 () at lisp.h:1007
#20 0x0000555555703167 in internal_condition_case (bfun=bfun@entry=0x5555556964e0 <command_loop_1>, handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x55555568cc10 <cmd_error>) at eval.c:1359
#21 0x0000555555687194 in command_loop_2 (ignore=ignore@entry=XIL(0)) at lisp.h:1007
#22 0x00005555557030c1 in internal_catch (tag=tag@entry=XIL(0xd710), func=func@entry=0x555555687170 <command_loop_2>, arg=arg@entry=XIL(0)) at eval.c:1120
#23 0x000055555568713b in command_loop () at lisp.h:1007
#24 0x000055555568c826 in recursive_edit_1 () at keyboard.c:718
#25 0x000055555568cb52 in Frecursive_edit () at keyboard.c:790
#26 0x00005555555a0fcc in main (argc=2, argv=<optimized out>) at emacs.c:2047
Currently logging to "gdb.txt".
Logs will be appended to the log file.
Output will be logged and displayed.
Debug output will be logged and displayed.
Continuing.
[Thread 0x7ffff1133640 (LWP 49752) exited]
[Thread 0x7ffff2cf3fc0 (LWP 49748) exited]
[Inferior 1 (process 49748) exited normally]

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: 44180@debbugs.gnu.org
> Date: Tue, 27 Oct 2020 12:48:52 -0700
> 
> Okay, hope this is helpful. I start in a workspace with only the
> terminal, do the gdb dance, and when I run "r -Q" the first frame
> appears, in stacked mode, taking up the whole screen. I create a second
> frame: now i3 has a vertical stack of three windows: terminal, emacs1
> and emacs2 -- emacs2 is focused.
> 
> I shut off blink cursor and global eldoc, note the frame addresses, then
> move focus "wrap-around" style down and back around to the terminal, so
> the emacs1 window (which is the "stuck" one in master) never receives
> focus (that might not be important).
> 
> Back in the terminal I pause execution, set the expose_frame breakpoint,
> turn on logging, and continue. Then move focus down to emacs1, back up
> to the terminal, see the breakpoint has triggered, get a backtrace, and
> confirm that the frame in question is indeed emacs1.
> 
> I did that exact routine in both master and a "revert" branch, with the
> commit reverted.

The backtraces look identical.  So does this mean expose_frame returns
immediately in the "master" case without doing anything, but in the
"revert" case it doesn't return?  If so, is the reason the fact that
the problematic frame is marked as "garbaged" in the "master" case,
but not in the "revert" case?

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Cc: 44180@debbugs.gnu.org
>> Date: Tue, 27 Oct 2020 12:48:52 -0700
>> 
>> Okay, hope this is helpful. I start in a workspace with only the
>> terminal, do the gdb dance, and when I run "r -Q" the first frame
>> appears, in stacked mode, taking up the whole screen. I create a second
>> frame: now i3 has a vertical stack of three windows: terminal, emacs1
>> and emacs2 -- emacs2 is focused.
>> 
>> I shut off blink cursor and global eldoc, note the frame addresses, then
>> move focus "wrap-around" style down and back around to the terminal, so
>> the emacs1 window (which is the "stuck" one in master) never receives
>> focus (that might not be important).
>> 
>> Back in the terminal I pause execution, set the expose_frame breakpoint,
>> turn on logging, and continue. Then move focus down to emacs1, back up
>> to the terminal, see the breakpoint has triggered, get a backtrace, and
>> confirm that the frame in question is indeed emacs1.
>> 
>> I did that exact routine in both master and a "revert" branch, with the
>> commit reverted.
>
> The backtraces look identical.  So does this mean expose_frame returns
> immediately in the "master" case without doing anything, but in the
> "revert" case it doesn't return?  If so, is the reason the fact that
> the problematic frame is marked as "garbaged" in the "master" case,
> but not in the "revert" case?

(I haven't had time to tackle this, and now will be away from the X11
machine for a week. Will report back in a couple weeks.)

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

>> The backtraces look identical.  So does this mean expose_frame returns
>> immediately in the "master" case without doing anything, but in the
>> "revert" case it doesn't return?  If so, is the reason the fact that
>> the problematic frame is marked as "garbaged" in the "master" case,
>> but not in the "revert" case?
>
> (I haven't had time to tackle this, and now will be away from the X11
> machine for a week. Will report back in a couple weeks.)

This was a year ago -- are you still seeing this problem on the trunk?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Eric Abrahamsen]

On 04/24/22 16:08 PM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>>> The backtraces look identical.  So does this mean expose_frame returns
>>> immediately in the "master" case without doing anything, but in the
>>> "revert" case it doesn't return?  If so, is the reason the fact that
>>> the problematic frame is marked as "garbaged" in the "master" case,
>>> but not in the "revert" case?
>>
>> (I haven't had time to tackle this, and now will be away from the X11
>> machine for a week. Will report back in a couple weeks.)
>
> This was a year ago -- are you still seeing this problem on the trunk?

Nope! Guess it fixed itself in the meantime. Please go ahead and close.

bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Nope! Guess it fixed itself in the meantime. Please go ahead and close.

OK; done.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no