GNU bug report logs - #35961
27.0.50; Sometimes frame freezes and stops updating (almost entirely)

Previous Next

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

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

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

From: Dmitry Gutov <dgutov <at> servers.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; Sometimes frame freezes and stops updating (almost entirely)
Date: Tue, 28 May 2019 18:06:44 +0300

The windows' contents stay almost unchanged (with the exception of some
visual glitches) in response to most commands I issue. Some weird
effects can remain, like blinking cursor(s).

It's not a Emacs freeze, because I can switch to another application and
back, and *then* the contents become updated (and still frozen
afterwards), so I can issue a command, switch back and forth and see the
result.

It happens randomly with no particular reproduction scenario. I can
never see it for a week or two, and then it happens 2-3 times a day. The
only thing in common I remember is there's usually an
*rspec-compilation* buffer shown (a third-party compilation major mode).
It often contains long lines, and while compilation is running, it
enacts a certain strain on our display engine.

What I tried:

- Evaluating

    (modify-all-frames-parameters '((inhibit-double-buffering . t)))

  => the frozen frame does not get better.

- Creating a new frame with 'C-x 5 2'. The result is a responsive frame,
  all the while the previous one is in that weird state. Further, the
  said previous frame can start updating the area of the screen where
  the new frame was initially displayed. That area doesn't change as I
  move/resize the new frame.

It's not a new problem, I've been seeing it for months on and off. It's
just weird and infrequent enough that I've held off from reporting.

In GNU Emacs 27.0.50 (build 55, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
 of 2019-05-19 built on zappa
Repository revision: 613565494d048ec758d5051484a17fdeccd42f00
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12001000
System Description: Ubuntu 18.04.2 LTS

Recent messages:
Source file ‘/home/dgutov/vc/emacs-master/lisp/filenotify.el’ newer than 
byte-compiled file
Loading autorevert (compiled; note, source file is newer)...done
Loading help-at-pt...done
Loading /home/dgutov/.custom.el (source)...done
Source file ‘/home/dgutov/vc/emacs-master/lisp/emacs-lisp/advice.el’ 
newer than byte-compiled file
Loading quail/cyrillic...done
Loading /home/dgutov/.emacs.d/site-lisp/.emacs-loaddefs.el (source)...done
Switching to window configuration: nil
Highlight tail mode enabled
For information about GNU Emacs and the GNU system, type C-h C-a.

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

Important settings:
  value of $LC_MONETARY: ru_RU.UTF-8
  value of $LC_NUMERIC: ru_RU.UTF-8
  value of $LC_TIME: ru_RU.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effect:
  paredit-mode: t
  save-place-mode: t
  global-page-break-lines-mode: t
  page-break-lines-mode: t
  projectile-mode: t
  hes-mode: t
  global-robe-mode: t
  flymake-mode: t
  global-company-mode: t
  company-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  global-diff-hl-mode: t
  savehist-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  global-whitespace-cleanup-mode: t
  whitespace-cleanup-mode: t
  ido-ubiquitous-mode: t
  ido-everywhere: t
  show-paren-mode: t
  electric-pair-mode: t
  delete-selection-mode: t
  cua-mode: t
  winner-mode: t
  global-auto-revert-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  auto-fill-function: yas--auto-fill
  transient-mark-mode: t

Load-path shadows:
/home/dgutov/.emacs.d/site-lisp/smartrep.el/smartrep hides 
~/.emacs.d/site-lisp/smartrep
/home/dgutov/.emacs.d/site-lisp/diff-hl/diff-hl-dired hides 
/home/dgutov/.emacs.d/elpa/diff-hl-20190223.2333/diff-hl-dired
/home/dgutov/.emacs.d/site-lisp/diff-hl/diff-hl-margin hides 
/home/dgutov/.emacs.d/elpa/diff-hl-20190223.2333/diff-hl-margin
/home/dgutov/.emacs.d/site-lisp/diff-hl/diff-hl hides 
/home/dgutov/.emacs.d/elpa/diff-hl-20190223.2333/diff-hl
/home/dgutov/.emacs.d/site-lisp/diff-hl/diff-hl-amend hides 
/home/dgutov/.emacs.d/elpa/diff-hl-20190223.2333/diff-hl-amend
/home/dgutov/.emacs.d/site-lisp/diff-hl/diff-hl-flydiff hides 
/home/dgutov/.emacs.d/elpa/diff-hl-20190223.2333/diff-hl-flydiff

Features:
(shadow sort mail-extr emacsbug smex disp-table paredit saveplace
tango-plus-theme page-break-lines smart-mode-line-light-theme
smart-mode-line rich-minority highlight-tail projectile grep ibuf-ext
ibuffer ibuffer-loaddefs highlight-escape-sequences company-oddmuse
company-keywords company-etags company-gtags company-dabbrev-code
company-dabbrev company-files company-capf company-cmake company-xcode
company-clang company-semantic company-eclim company-template
company-bbdb company-robe robe url-http url-auth url-gw nsm url
url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util mm-view mml-smime smime dig mailcap etags fileloop
generator xref project inf-ruby ruby-end ruby-mode flymake-proc flymake
warnings thingatpt smie compile files-x company undo-tree diff diff-hl
smartrep cl face-remap vc-hg vc-git vc-dir ewoc diff-mode savehist
yasnippet-snippets yasnippet whitespace-cleanup-mode whitespace
ido-completing-read+ memoize s cus-edit wid-edit minibuf-eldef ido paren
elec-pair delsel cua-base winner .emacs-loaddefs cl-extra prelude esk
devenv commit-patch-buffer log-edit message rmc puny format-spec rfc822
mml mml-sec epa epg gnus-util rmail dframe rmail-loaddefs
text-property-search time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils gmm-utils mailheader pcvs-util add-log vc
vc-dispatcher point-stack mmm mmm-defaults mmm-auto mmm-vars mmm-utils
mmm-compat progmodes keys find-func quail help-mode windmove hippie
hippie-exp comint derived ansi-color dired desktop frameset easy-mmode
pcase dired-loaddefs winring ring misc prefs defuns advice help-at-pt
autorevert filenotify cus-start cus-load mule-util edmacro kmacro rx
info package easymenu epg-config 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 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 menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame 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 minibuffer
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
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 420186 23205)
 (symbols 48 22245 0)
 (strings 32 70476 6962)
 (string-bytes 1 2380999)
 (vectors 16 24385)
 (vector-slots 8 311017 14478)
 (floats 8 86 88)
 (intervals 56 639 0)
 (buffers 992 12))

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: 35961 <at> debbugs.gnu.org
Subject: Re: bug#35961: Acknowledgement (27.0.50; Sometimes frame freezes and
 stops updating (almost entirely))
Date: Tue, 28 May 2019 18:15:00 +0300

*Facepalm*

Please use my usual email when responding, if possible.

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

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 35961 <at> debbugs.gnu.org
Subject: Re: bug#35961: 27.0.50;
 Sometimes frame freezes and stops updating (almost entirely)
Date: Tue, 28 May 2019 17:04:26 +0100

Dmitry Gutov <dgutov <at> servers.com> writes:

> The windows' contents stay almost unchanged (with the exception of some
> visual glitches) in response to most commands I issue. Some weird
> effects can remain, like blinking cursor(s).
>
> It's not a Emacs freeze, because I can switch to another application and
> back, and *then* the contents become updated (and still frozen
> afterwards), so I can issue a command, switch back and forth and see the
> result.
>
> It happens randomly with no particular reproduction scenario. I can
> never see it for a week or two, and then it happens 2-3 times a day. The
> only thing in common I remember is there's usually an
> *rspec-compilation* buffer shown (a third-party compilation major mode).
> It often contains long lines, and while compilation is running, it
> enacts a certain strain on our display engine.
>
> What I tried:
>
> - Evaluating
>
>     (modify-all-frames-parameters '((inhibit-double-buffering . t)))
>
>   => the frozen frame does not get better.
>
> - Creating a new frame with 'C-x 5 2'. The result is a responsive frame,
>   all the while the previous one is in that weird state. Further, the
>   said previous frame can start updating the area of the screen where
>   the new frame was initially displayed. That area doesn't change as I
>   move/resize the new frame.
>
> It's not a new problem, I've been seeing it for months on and off. It's
> just weird and infrequent enough that I've held off from reporting.

I use xmonad as my (tiling) window manager, and FWIW your description
sounds almost identical to what happens to my Emacs session (master and
emacs-26, with or without -Q) when I type C-z (suspend-frame), which in
turn calls iconify-or-deiconify-frame.

-- 
Basil

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> servers.com>
Cc: 35961 <at> debbugs.gnu.org
Subject: Re: bug#35961: 27.0.50;
 Sometimes frame freezes and stops updating (almost entirely)
Date: Tue, 28 May 2019 21:41:15 +0300

> From: Dmitry Gutov <dgutov <at> servers.com>
> Date: Tue, 28 May 2019 18:06:44 +0300
> 
> - Creating a new frame with 'C-x 5 2'. The result is a responsive frame,
>    all the while the previous one is in that weird state.

This bit almost certainly means that it's not an Emacs problem, but
something related to the other software on your system.  Emacs's
display engine updates all the frames one after the other, in a single
thread, so the situation where one frame is updated, but another
isn't, is simply impossible, as far as the Emacs code is concerned.

Did you try looking at your system's logs for the times when these
freezes happen?  Or search the Internet for similar reports, not
necessarily related to Emacs?

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 35961 <at> debbugs.gnu.org
Subject: Re: bug#35961: 27.0.50; Sometimes frame freezes and stops updating
 (almost entirely)
Date: Thu, 30 May 2019 19:30:29 +0300

On 28.05.2019 19:04, Basil L. Contovounesios wrote:

> I use xmonad as my (tiling) window manager, and FWIW your description
> sounds almost identical to what happens to my Emacs session (master and
> emacs-26, with or without -Q) when I type C-z (suspend-frame), which in
> turn calls iconify-or-deiconify-frame.

Interesting. I think I've heard about xmonad-related problems before. 
Maybe there are even existing bug reports.

So you can reproduce the problem at will, and there's no way to "resume" 
a frame after it happens?

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 35961 <at> debbugs.gnu.org
Subject: Re: bug#35961: 27.0.50; Sometimes frame freezes and stops updating
 (almost entirely)
Date: Thu, 30 May 2019 19:37:26 +0300

On 28.05.2019 21:41, Eli Zaretskii wrote:
>> From: Dmitry Gutov <dgutov <at> servers.com>
>> Date: Tue, 28 May 2019 18:06:44 +0300
>>
>> - Creating a new frame with 'C-x 5 2'. The result is a responsive frame,
>>     all the while the previous one is in that weird state.
> 
> This bit almost certainly means that it's not an Emacs problem, but
> something related to the other software on your system. 

That's possible, actually. I've had another program (a terminal 
emulator) show similar behavior. I'm using a somewhat outdated desktop 
environment (Unity 7), so there might be some bugs in its windowing 
code. A reboot usually solves the problem for a while.

> Emacs's
> display engine updates all the frames one after the other, in a single
> thread, so the situation where one frame is updated, but another
> isn't, is simply impossible, as far as the Emacs code is concerned.

Having said the above, surely there is also some code that passes the 
rendered frame contents to the windowing system, or the graphical toolkit?

> Did you try looking at your system's logs for the times when these
> freezes happen?  Or search the Internet for similar reports, not
> necessarily related to Emacs?

I will try, thank you.

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

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 35961 <at> debbugs.gnu.org
Subject: Re: bug#35961: 27.0.50;
 Sometimes frame freezes and stops updating (almost entirely)
Date: Thu, 30 May 2019 18:05:29 +0100

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> On 28.05.2019 19:04, Basil L. Contovounesios wrote:
>
>> I use xmonad as my (tiling) window manager, and FWIW your description
>> sounds almost identical to what happens to my Emacs session (master and
>> emacs-26, with or without -Q) when I type C-z (suspend-frame), which in
>> turn calls iconify-or-deiconify-frame.
>
> Interesting. I think I've heard about xmonad-related problems before. Maybe
> there are even existing bug reports.

Quite likely, but I'm not sure I'd consider my description a "problem".
AFAIK, xmonad doesn't have a concept of iconifying a frame by default,
so the current behaviour of suspend-frame seems fine to me.

> So you can reproduce the problem at will,

Yes, all it takes is C-z.

> and there's no way to "resume" a frame after it happens?

The only way I know to "resume" the frame is to switch to another frame
and back again.

-- 
Basil

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 35961 <at> debbugs.gnu.org
Subject: Re: bug#35961: 27.0.50; Sometimes frame freezes and stops updating
 (almost entirely)
Date: Thu, 30 May 2019 20:37:35 +0300

On 30.05.2019 20:05, Basil L. Contovounesios wrote:

> Quite likely, but I'm not sure I'd consider my description a "problem".
> AFAIK, xmonad doesn't have a concept of iconifying a frame by default,
> so the current behaviour of suspend-frame seems fine to me.

OK.

>> and there's no way to "resume" a frame after it happens?
> 
> The only way I know to "resume" the frame is to switch to another frame
> and back again.

Hmm, it that works, it's likely a different issue. Switching to another 
frame and back doesn't help in my experience.

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

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 35961 <at> debbugs.gnu.org
Subject: Re: bug#35961: 27.0.50;
 Sometimes frame freezes and stops updating (almost entirely)
Date: Thu, 30 May 2019 21:25:18 +0100

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> On 30.05.2019 20:05, Basil L. Contovounesios wrote:
>
>>> and there's no way to "resume" a frame after it happens?
>>
>> The only way I know to "resume" the frame is to switch to another frame
>> and back again.
>
> Hmm, it that works, it's likely a different issue. Switching to another frame
> and back doesn't help in my experience.

Sorry, what I said is not true: the suspended frame seems to be resumed
only when it is resized (tiled) by the creation of some other frame,
e.g. another Emacs frame or a terminal emulator window.

-- 
Basil

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 35961 <at> debbugs.gnu.org
Subject: Re: bug#35961: 27.0.50; Sometimes frame freezes and stops updating
 (almost entirely)
Date: Fri, 31 May 2019 18:25:54 +0300

> Cc: 35961 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Thu, 30 May 2019 19:37:26 +0300
> 
> > Emacs's
> > display engine updates all the frames one after the other, in a single
> > thread, so the situation where one frame is updated, but another
> > isn't, is simply impossible, as far as the Emacs code is concerned.
> 
> Having said the above, surely there is also some code that passes the 
> rendered frame contents to the windowing system, or the graphical toolkit?

Yes, but if you are thinking about some thread in that
toolkit/windowing library getting stuck while others continue working,
you can try starting Emacs in X synchronous mode (etc/DEBUG has the
details), then Emacs will wait for each X call to return, and X will
not return until the request completes.  If you see the same problem
in that case, i.e. some frame(s) become not responsive while others
don't, it is almost certainly not an Emacs problem.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 35961 <at> debbugs.gnu.org
Subject: Re: bug#35961: 27.0.50; Sometimes frame freezes and stops updating
 (almost entirely)
Date: Mon, 10 Jun 2019 02:40:03 +0300

On 31.05.2019 18:25, Eli Zaretskii wrote:

> Yes, but if you are thinking about some thread in that
> toolkit/windowing library getting stuck while others continue working,
> you can try starting Emacs in X synchronous mode (etc/DEBUG has the
> details), then Emacs will wait for each X call to return, and X will
> not return until the request completes.  If you see the same problem
> in that case, i.e. some frame(s) become not responsive while others
> don't, it is almost certainly not an Emacs problem.

Thanks, I'll look into that if the problem persists (and if I can find a 
repro).

The last time it happened, though, I observed the same effect in another 
program, so this is probably not Emacs's fault. And I haven't seen the 
problem since the day this bug was filed.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 35961 <at> debbugs.gnu.org
Subject: Re: bug#35961: 27.0.50; Sometimes frame freezes and stops updating
 (almost entirely)
Date: Wed, 25 Sep 2019 16:42:35 +0200

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> On 31.05.2019 18:25, Eli Zaretskii wrote:
>
>> Yes, but if you are thinking about some thread in that
>> toolkit/windowing library getting stuck while others continue working,
>> you can try starting Emacs in X synchronous mode (etc/DEBUG has the
>> details), then Emacs will wait for each X call to return, and X will
>> not return until the request completes.  If you see the same problem
>> in that case, i.e. some frame(s) become not responsive while others
>> don't, it is almost certainly not an Emacs problem.
>
> Thanks, I'll look into that if the problem persists (and if I can find
> a repro).
>
> The last time it happened, though, I observed the same effect in
> another program, so this is probably not Emacs's fault. And I haven't
> seen the problem since the day this bug was filed.

This seems unreproducible, and the last action here was 15 weeks ago, so
I'm closing this bug report.  If the problem reappears, please reopen.

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

Previous Next

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