bug#51336: 29.0.50; Application not responding

bug#51336: 29.0.50; Application not responding

[Kirill A. Korinsky via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 11225 bytes --]


Here a tricky bug, and probably is related #50641 and I never seems this
behaviour before fix for #50534.

When I have open emacs one another virtual screen, it has openned magit
status buffer, and I've make a click and hold on emacs's icon on desk =>
it shows "Application not responding" (see screenshot).



Not always, but ofthen enough.

When I switch to actual virtual screen which has emacs => it responses
well.

In GNU Emacs 29.0.50 (build 1, x86_64-apple-darwin20.6.0, NS appkit-2022.60 Version 11.6 (Build 20G165))
of 2021-10-20 built on MacBook-Pro.sa31-cbt.catap.net
Repository revision: 5f5189e9be6c70c4db99e8057287d16955b9c620
Repository branch: HEAD
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.6

Configured using:
'configure --prefix=/opt/local --disable-silent-rules --without-dbus
--without-gconf --without-libotf --without-m17n-flt --with-libgmp
--with-gnutls --with-json --with-xml2 --with-modules --infodir
/opt/local/share/info/emacs --with-ns --with-lcms2 --without-harfbuzz
--without-imagemagick --without-xaw3d --with-native-compilation
--with-rsvg 'CFLAGS=-pipe -Os
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch
x86_64' 'CPPFLAGS=-I/opt/local/include
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk'
'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names
-Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk
-arch x86_64''

Configured features:
ACL GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY KQUEUE NS PDUMPER PNG RSVG THREADS TIFF TOOLKIT_SCROLL_BARS XIM
ZLIB

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

Major mode: Magit

Minor modes in effect:
  flyspell-lazy-mode: t
  save-place-mode: t
  global-so-long-mode: t
  diff-hl-margin-mode: t
  magit-gitflow-mode: t
  gcmh-mode: t
  global-hl-line-mode: t
  hl-line-mode: t
  winner-mode: t
  smartparens-global-mode: t
  ws-butler-global-mode: t
  global-emojify-mode: t
  emojify-mode: t
  global-undo-fu-session-mode: t
  undo-fu-mode: t
  global-flycheck-mode: t
  which-key-mode: t
  better-jumper-mode: t
  company-tng-mode: t
  global-company-mode: t
  company-mode: t
  ivy-rich-project-root-cache-mode: t
  ivy-rich-mode: t
  ivy-mode: t
  volatile-highlights-mode: t
  global-git-commit-mode: t
  shell-dirtrack-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  savehist-mode: t
  recentf-mode: t
  persp-mode: t
  dtrt-indent-mode: t
  doom-modeline-mode: t
  solaire-global-mode: t
  solaire-mode: t
  delete-selection-mode: t
  projectile-mode: t
  ns-auto-titlebar-mode: t
  +popup-mode: t
  general-override-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  window-divider-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/Users/catap/src/doom-emacs/.local/straight/build-29.0.50/use-package/use-package-diminish hides /Users/catap/src/doom-emacs/.local/straight/repos/use-package/use-package-diminish
/Users/catap/src/doom-emacs/.local/straight/build-29.0.50/use-package/use-package hides /Users/catap/src/doom-emacs/.local/straight/repos/use-package/use-package
/Users/catap/src/doom-emacs/.local/straight/build-29.0.50/use-package/use-package-lint hides /Users/catap/src/doom-emacs/.local/straight/repos/use-package/use-package-lint
/Users/catap/src/doom-emacs/.local/straight/build-29.0.50/use-package/use-package-delight hides /Users/catap/src/doom-emacs/.local/straight/repos/use-package/use-package-delight
/Users/catap/src/doom-emacs/.local/straight/build-29.0.50/use-package/use-package-jump hides /Users/catap/src/doom-emacs/.local/straight/repos/use-package/use-package-jump
/Users/catap/src/doom-emacs/.local/straight/build-29.0.50/use-package/use-package-core hides /Users/catap/src/doom-emacs/.local/straight/repos/use-package/use-package-core
/Users/catap/src/doom-emacs/.local/straight/build-29.0.50/use-package/use-package-ensure hides /Users/catap/src/doom-emacs/.local/straight/repos/use-package/use-package-ensure
/Users/catap/src/doom-emacs/.local/straight/build-29.0.50/use-package/use-package-bind-key hides /Users/catap/src/doom-emacs/.local/straight/repos/use-package/use-package-bind-key
/Users/catap/src/doom-emacs/.local/straight/build-29.0.50/bind-key/bind-key hides /Users/catap/src/doom-emacs/.local/straight/repos/use-package/bind-key
/Users/catap/src/doom-emacs/.local/straight/build-29.0.50/straight/straight-x hides /Users/catap/src/doom-emacs/.local/straight/repos/straight.el/straight-x
/Users/catap/src/doom-emacs/.local/straight/build-29.0.50/apel/install hides /Users/catap/src/doom-emacs/.local/straight/repos/straight.el/install
/Users/catap/src/doom-emacs/.local/straight/build-29.0.50/straight/straight hides /Users/catap/src/doom-emacs/.local/straight/repos/straight.el/straight
/Users/catap/src/doom-emacs/.local/straight/build-29.0.50/straight/straight-ert-print-hack hides /Users/catap/src/doom-emacs/.local/straight/repos/straight.el/straight-ert-print-hack
/Users/catap/src/doom-emacs/.local/straight/build-29.0.50/cmake-mode/cmake-mode hides /opt/local/share/emacs/site-lisp/cmake-mode
/Users/catap/src/doom-emacs/.local/straight/repos/straight.el/indent hides /Applications/MacPorts/Emacs.app/Contents/Resources/lisp/indent
/Users/catap/src/doom-emacs/.local/straight/build-29.0.50/transient/transient hides /Applications/MacPorts/Emacs.app/Contents/Resources/lisp/transient
/Users/catap/src/doom-emacs/.local/straight/build-29.0.50/xref/xref hides /Applications/MacPorts/Emacs.app/Contents/Resources/lisp/progmodes/xref
/Users/catap/src/doom-emacs/.local/straight/build-29.0.50/project/project hides /Applications/MacPorts/Emacs.app/Contents/Resources/lisp/progmodes/project
/Users/catap/src/doom-emacs/.local/straight/build-29.0.50/flim/sasl hides /Applications/MacPorts/Emacs.app/Contents/Resources/lisp/net/sasl

Features:
(shadow sort disp-table whitespace flyspell-lazy flyspell ispell
vi-tilde-fringe display-line-numbers highlight-indent-guides
adaptive-wrap mail-extr emacsbug sendmail amx flycheck-popup-tip popup
saveplace so-long dired-aux vc-hg vc-git vc-svn diredfl dired-x ffap
docker-tramp tramp-cache tramp tramp-loaddefs trampver tramp-integration
files-x tramp-compat parse-time ls-lisp diff-hl-margin diff-hl-dired
diff-hl log-view vc-dir ewoc vc vc-dispatcher goto-addr hide-mode-line
magit-extras magit-gitflow gcmh hl-line winner smartparens-config
smartparens-org smartparens-text smartparens ws-butler emojify apropos
tar-mode arc-mode archive-mode ht undo-fu-session undo-fu
flycheck-package package-lint finder finder-inf flycheck cursor-sensor
counsel-projectile which-key better-jumper company-tng company-capf
company etags fileloop generator ivy-xref ivy-avy avy ivy-rich counsel
xdg swiper ivy flx ivy-faces ivy-overlay colir color xref project
volatile-highlights magit-todos pcre2el rxt re-builder hl-todo async 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 oc-basic
bibtex iso8601 ol org-keys oc org-compat org-macs org-loaddefs find-func
cal-menu calendar cal-loaddefs github-review ghub-graphql treepy gsexp
ghub url-http url-gw nsm url-auth let-alist gnutls deferred a
magit-autoloads magit-submodule magit-obsolete magit-popup magit-blame
magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch
magit-clone magit-remote magit-commit magit-sequence magit-notes
magit-worktree magit-tag magit-merge magit-branch magit-reset
magit-files magit-refs magit-status magit magit-repos magit-apply
magit-wip magit-log which-func imenu magit-diff smerge-mode diff
diff-mode magit-core magit-autorevert magit-margin magit-transient
magit-process core-packages package browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
mailcap url-handlers url-parse url-vars git-commit log-edit message rmc
puny dired dired-loaddefs rfc822 mml mml-sec epa epg rfc6068 epg-config
gnus-util rmail rmail-loaddefs auth-source password-cache json map
time-date mm-decode mm-bodies mm-encode mailabbrev mail-utils gmm-utils
mailheader pcvs-util add-log magit-mode transient edmacro kmacro
format-spec magit-git magit-section magit-utils crm with-editor shell
pcomplete doom-snippets doom-snippets-lib yasnippet elisp-mode savehist
recentf tree-widget wid-edit server autorevert filenotify
persistent-soft list-utils pcache eieio-base eieio eieio-core
eieio-loaddefs font-utils unicode-fonts persp-mode dtrt-indent advice
doom-modeline doom-modeline-segments doom-modeline-env
doom-modeline-core shrink-path f s all-the-icons all-the-icons-faces
data-material data-weathericons data-octicons data-fileicons
data-faicons data-alltheicons dash doom-themes-ext-treemacs
doom-themes-ext-org solaire-mode face-remap doom-one-theme doom-themes
doom-themes-base delsel projectile lisp-mnt mail-parse rfc2231 rfc2047
rfc2045 mm-util ietf-drums mail-prsvr grep compile text-property-search
comint ansi-color ring ibuf-ext ibuffer ibuffer-loaddefs thingatpt
smartparens-lua ns-auto-titlebar derived core-editor core-projects
core-ui easy-mmode core-keybinds pp general use-package-core
core-modules tex-site cl core comp comp-cstr warnings rx cl-seq cl-extra
help-mode seq byte-opt bytecomp byte-compile cconv core-lib pcase subr-x
cl-macs gv cl-loaddefs cl-lib chemacs iso-transl tooltip eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/ns-win
ns-win ucs-normalize mule-util term/common-win tool-bar dnd fontset
image regexp-opt fringe tabulated-list replace newcomment text-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads kqueue
cocoa ns lcms2 multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 905713 310012)
(symbols 48 60357 48)
(strings 32 219973 40737)
(string-bytes 1 6283885)
(vectors 16 139273)
(vector-slots 8 4892699 234722)
(floats 8 1020 1974)
(intervals 56 3385 1569)
(buffers 992 16))


--
wbr, Kirill


[-- Attachment #1.2.1: Type: text/html, Size: 17402 bytes --]

[-- Attachment #1.2.2: Screenshot 2021-10-22 at 19.08.30.png --]
[-- Type: image/png, Size: 33657 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#51336: 29.0.50; Application not responding

[Lars Ingebrigtsen]

"Kirill A. Korinsky" <kirill@korins.ky> writes:

> When I have open emacs one another virtual screen, it has openned magit
> status buffer, and I've make a click and hold on emacs's icon on desk =>
> it shows "Application not responding" (see screenshot).

I'm not familiar with Magit -- does the status buffer do anything
special that could lead to Emacs being seemingly unresponsive?  What
does it look like?  :-)

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

bug#51336: 29.0.50; Application not responding

[Kirill A. Korinsky via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 300 bytes --]

> I'm not familiar with Magit -- does the status buffer do anything
> special that could lead to Emacs being seemingly unresponsive?  What
> does it look like?  :-)


You may read a lot about it here: https://magit.vc

It runs a few git subprocess I guess.

And it looks like this:


--
wbr, Kirill


[-- Attachment #1.2.1: Type: text/html, Size: 1476 bytes --]

[-- Attachment #1.2.2: Screenshot 2021-10-24 at 21.43.57.png --]
[-- Type: image/png, Size: 248393 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#51336: 29.0.50; Application not responding

[Lars Ingebrigtsen]

"Kirill A. Korinsky" <kirill@korins.ky> writes:

> It runs a few git subprocess I guess.

It runs them in the background, though, so Emacs is still responsive
while it's running?

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

bug#51336: 29.0.50; Application not responding

[Kirill A. Korinsky via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 396 bytes --]

yes

--
wbr, Kirill

> On 24. Oct 2021, at 21:45, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
> "Kirill A. Korinsky" <kirill@korins.ky> writes:
> 
>> It runs a few git subprocess I guess.
> 
> It runs them in the background, though, so Emacs is still responsive
> while it's running?
> 
> --
> (domestic pets only, the antidote for overdose, milk.)
>   bloggy blog: http://lars.ingebrigtsen.no


[-- Attachment #1.2: Type: text/html, Size: 1585 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#51336: 29.0.50; Application not responding

[Alan Third]

On Fri, Oct 22, 2021 at 07:13:34PM +0200, Kirill A. Korinsky via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
> 
> Here a tricky bug, and probably is related #50641 and I never seems this
> behaviour before fix for #50534.
> 
> When I have open emacs one another virtual screen, it has openned magit
> status buffer, and I've make a click and hold on emacs's icon on desk =>
> it shows "Application not responding" (see screenshot).
> 
> 
> 
> Not always, but ofthen enough.
> 
> When I switch to actual virtual screen which has emacs => it responses
> well.

This sounds like Emacs is being put in "app nap" mode by the OS and
therefore the NS run loop is suspended.

Either that or magit is somehow preventing Emacs from running the run
loop, but that would prevent you from being able to do anything at
all, so seems unlikely.

I can't replicate it and I don't have much in the way of suggestions.
Perhaps stick an NSLog message in ns_select and see if it continues to
be called when Emacs is "not responding".
-- 
Alan Third

bug#51336: 29.0.50; Application not responding

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

> I can't replicate it and I don't have much in the way of suggestions.
> Perhaps stick an NSLog message in ns_select and see if it continues to
> be called when Emacs is "not responding".

I'm not able to reproduce it, either.

Kirill, do you still see this issue in recent Emacs/OS versions?  If so,
do you have a complete recipe, starting from "emacs -Q", to reproduce the
problem?

bug#51336: 29.0.50; Application not responding

[Kirill A. Korinsky via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 1194 bytes --]

Tes, I just reproduced it on:

In GNU Emacs 29.0.50 (build 1, x86_64-apple-darwin21.3.0, NS appkit-2113.30 Version 12.2.1 (Build 21D62))
 of 2022-08-01 built on montereyx.internal.macports.net
Repository revision: f2465b6b2ff64fe81612b5a02c16a98942c5ca57
Repository branch: HEAD
Windowing system distributor 'Apple', version 10.3.2113
System Description:  macOS 12.5.1

Configured using:
 'configure --prefix=/opt/local --disable-silent-rules --without-dbus
 --without-gconf --without-libotf --without-m17n-flt --with-libgmp
 --with-gnutls --with-json --with-xml2 --with-modules --infodir
 /opt/local/share/info/emacs --with-sqlite3 --with-webp --with-ns
 --with-lcms2 --without-harfbuzz --without-imagemagick --without-xaw3d
 --with-rsvg --with-native-compilation 'CFLAGS=-pipe -Os
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -arch
 x86_64' 'CPPFLAGS=-I/opt/local/include
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk'
 'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-rpath
 /opt/local/lib/gcc12 -Wl,-no_pie
 -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk
 -arch x86_64''

--
wbr, Kirill


[-- Attachment #1.2: Type: text/html, Size: 2508 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#51336: 29.0.50; Application not responding

[Lars Ingebrigtsen]

"Kirill A. Korinsky" <kirill@korins.ky> writes:

> Tes, I just reproduced it on:
>
> In GNU Emacs 29.0.50 (build 1, x86_64-apple-darwin21.3.0, NS appkit-2113.30
> Version 12.2.1 (Build 21D62))
>  of 2022-08-01 built on montereyx.internal.macports.net
> Repository revision: f2465b6b2ff64fe81612b5a02c16a98942c5ca57

That's a version that's over a month old, though.

In any case, do you have a recipe to reproduce the problem, starting
from "emacs -Q"?

bug#51336: 29.0.50; Application not responding

[Kirill A. Korinsky via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 905 bytes --]

I'll try to upgrade my emacs to the last version in days.

Reproducing, wel.. It isn't easy.

I feel that magit, using external screen and switching between workspace is part of issue.

When I wrote an email that I can reproduce it => I simple click by emacs icon in the dock and saw "Application not responsed".

--
wbr, Kirill

> On 13. Sep 2022, at 17:02, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
> "Kirill A. Korinsky" <kirill@korins.ky> writes:
> 
>> Tes, I just reproduced it on:
>> 
>> In GNU Emacs 29.0.50 (build 1, x86_64-apple-darwin21.3.0, NS appkit-2113.30
>> Version 12.2.1 (Build 21D62))
>> of 2022-08-01 built on montereyx.internal.macports.net
>> Repository revision: f2465b6b2ff64fe81612b5a02c16a98942c5ca57
> 
> That's a version that's over a month old, though.
> 
> In any case, do you have a recipe to reproduce the problem, starting
> from "emacs -Q"?


[-- Attachment #1.2: Type: text/html, Size: 2241 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#51336: 29.0.50; Application not responding

[Stefan Kangas]

"Kirill A. Korinsky" <kirill@korins.ky> writes:

> I'll try to upgrade my emacs to the last version in days.
>
> Reproducing, wel.. It isn't easy.
>
> I feel that magit, using external screen and switching between workspace is part of issue.
>
> When I wrote an email that I can reproduce it => I simple click by emacs icon in the dock and saw "Application not responsed".

(That was one year ago.)

Are you still seeing this issue?  I think we would need some way to reproduce
it to make any progress here.

bug#51336: 29.0.50; Application not responding

[Kirill A. Korinsky via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 128 bytes --]

Rarely.

I can recall that I have seen a couple of time this issue for the summer or a bit longer time.


--
wbr, Kirill

[-- Attachment #1.2: Type: text/html, Size: 894 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#51336: 29.0.50; Application not responding

[Eli Zaretskii]

> Cc: 51336@debbugs.gnu.org, Lars Magne Ingebrigtsen <larsi@gnus.org>,
>  Alan Third <alan@idiocy.org>
> Date: Sun, 3 Sep 2023 10:49:38 +0200
> From:  "Kirill A. Korinsky" via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Rarely.
> 
> I can recall that I have seen a couple of time this issue for the summer or a bit longer time.

The way forward here, I think, is to attach a debugger to Emacs when
this happens and post here the backtrace.  It could be that Emacs is
running GC, for example, or some other job that takes time, in which
case this is completely normal (given the Emacs architecture).

bug#51336: 29.0.50; Application not responding

[Kirill A. Korinsky]

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

Sorry for the very long response.

I've reproduced this issue a few times and attached lldb to see where it blocked.

All attempts were the same:

> (lldb) bt all
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
>   * frame #0: 0x00007ff817ed220a libsystem_kernel.dylib`__read_nocancel + 10
>     frame #1: 0x00007ff817de5fb9 libsystem_c.dylib`_sread + 16
>     frame #2: 0x00007ff817de5f68 libsystem_c.dylib`__srefill1 + 24
>     frame #3: 0x00007ff817de39b8 libsystem_c.dylib`__svfscanf_l + 2059
>     frame #4: 0x00007ff817e39a2f libsystem_c.dylib`scanf + 196
>     frame #5: 0x000000010ea0800a emacsql-sqlite`main + 234
>     frame #6: 0x00000001173db52e dyld`start + 462
> (lldb)


--
wbr, Kirill


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#51336: 29.0.50; Application not responding

[Eli Zaretskii]

> From: "Kirill A. Korinsky" <kirill@korins.ky>
> Date: Thu, 28 Dec 2023 18:55:02 +0100
> Cc: stefankangas@gmail.com,
>  51336@debbugs.gnu.org,
>  Lars Magne Ingebrigtsen <larsi@gnus.org>,
>  alan@idiocy.org
> 
> I've reproduced this issue a few times and attached lldb to see where it blocked.
> 
> All attempts were the same:
> 
> > (lldb) bt all
> > * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
> >   * frame #0: 0x00007ff817ed220a libsystem_kernel.dylib`__read_nocancel + 10
> >     frame #1: 0x00007ff817de5fb9 libsystem_c.dylib`_sread + 16
> >     frame #2: 0x00007ff817de5f68 libsystem_c.dylib`__srefill1 + 24
> >     frame #3: 0x00007ff817de39b8 libsystem_c.dylib`__svfscanf_l + 2059
> >     frame #4: 0x00007ff817e39a2f libsystem_c.dylib`scanf + 196
> >     frame #5: 0x000000010ea0800a emacsql-sqlite`main + 234
> >     frame #6: 0x00000001173db52e dyld`start + 462
> > (lldb)

Thanks, but I have no idea what this could mean.  What is the source
of the SIGSTOP signal?

bug#51336: 29.0.50; Application not responding

[Kirill Korinsky]

Greetings,

On Thu, 28 Dec 2023 20:47:34 +0100,
Eli Zaretskii wrote:
> 
> Thanks, but I have no idea what this could mean.  What is the source
> of the SIGSTOP signal?

It was wrong lead.

My magit uses emacsql with extreamly large DB (>140Mb) and that freez was
related to that DB.

After clean things up, that freez dissapears, but it allows to move forward and
find that seems a root cause.

Emacs was frozen (UI) and hasn't response to any command. Before that it had
happened I'd resized a window.

I attach and de-attach external screen quite often and it triggers the resize.

So, when it was frozen I've attached via lldb and get stack traces bellow.

It is reproducable, not each resize but often enough.

When it frozen, I need to kill it, otherwise it absolutle useless.

And this stack trace was obtained from local root d9462e24a967e32d550ee886b5150f0cc78358f6

(lldb) bt all
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007ff80d07596a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x00007ff80d075cd8 libsystem_kernel.dylib`mach_msg + 56
    frame #2: 0x00007ff80d17929d CoreFoundation`__CFRunLoopServiceMachPort + 319
    frame #3: 0x00007ff80d177928 CoreFoundation`__CFRunLoopRun + 1276
    frame #4: 0x00007ff80d176d6c CoreFoundation`CFRunLoopRunSpecific + 562
    frame #5: 0x00007ff815e245e6 HIToolbox`RunCurrentEventLoopInMode + 292
    frame #6: 0x00007ff815e2434a HIToolbox`ReceiveNextEventCommon + 594
    frame #7: 0x00007ff815e240e5 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 70
    frame #8: 0x00007ff80fbb1f6d AppKit`_DPSNextEvent + 927
    frame #9: 0x00007ff80fbb062a AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1394
    frame #10: 0x00007ff80fba2cd9 AppKit`-[NSApplication run] + 586
    frame #11: 0x0000000104b2449c Emacs`-[EmacsApp run] + 317
    frame #12: 0x0000000104b361ca Emacs`ns_read_socket_1 + 553
    frame #13: 0x0000000104a152bd Emacs`gobble_input + 243
    frame #14: 0x0000000104a13b7a Emacs`get_input_pending + 97
    frame #15: 0x0000000104a11eba Emacs`detect_input_pending_run_timers + 46
    frame #16: 0x0000000104ade227 Emacs`wait_reading_process_output + 4372
    frame #17: 0x0000000104944328 Emacs`sit_for + 436
    frame #18: 0x0000000104a0f21f Emacs`read_char + 7016
    frame #19: 0x0000000104a0b901 Emacs`read_key_sequence + 1247
    frame #20: 0x0000000104a09ec0 Emacs`command_loop_1 + 754
    frame #21: 0x0000000104a8932e Emacs`internal_condition_case + 87
    frame #22: 0x0000000104a09bbc Emacs`command_loop_2 + 41
    frame #23: 0x0000000104a88c5a Emacs`internal_catch + 81
    frame #24: 0x0000000104b5ee5f Emacs`command_loop.cold.1 + 72
    frame #25: 0x0000000104a09613 Emacs`command_loop + 132
    frame #26: 0x0000000104a09500 Emacs`recursive_edit_1 + 142
    frame #27: 0x0000000104a096fe Emacs`Frecursive_edit + 208
    frame #28: 0x0000000104a08a90 Emacs`main + 8278
    frame #29: 0x000000010546c52e dyld`start + 462
  thread #2, name = 'gmain'
    frame #0: 0x00007ff80d07dd4a libsystem_kernel.dylib`__select + 10
    frame #1: 0x00000001061209f0 libglib-2.0.0.dylib`g_poll + 505
    frame #2: 0x0000000106112049 libglib-2.0.0.dylib`g_main_context_iterate_unlocked + 297
    frame #3: 0x00000001061120fc libglib-2.0.0.dylib`g_main_context_iteration + 55
    frame #4: 0x00000001061130e7 libglib-2.0.0.dylib`glib_worker_main + 30
    frame #5: 0x0000000106137ce7 libglib-2.0.0.dylib`g_thread_proxy + 66
    frame #6: 0x00007ff80d0b24e1 libsystem_pthread.dylib`_pthread_start + 125
    frame #7: 0x00007ff80d0adf6b libsystem_pthread.dylib`thread_start + 15
  thread #3
    frame #0: 0x00007ff80d07a456 libsystem_kernel.dylib`__pselect + 10
    frame #1: 0x00007ff80d07a373 libsystem_kernel.dylib`pselect$DARWIN_EXTSN + 42
    frame #2: 0x0000000104b2534d Emacs`-[EmacsApp fd_handler:] + 201
    frame #3: 0x00007ff80dfce964 Foundation`__NSThread__start__ + 1009
    frame #4: 0x00007ff80d0b24e1 libsystem_pthread.dylib`_pthread_start + 125
    frame #5: 0x00007ff80d0adf6b libsystem_pthread.dylib`thread_start + 15
  thread #4, name = 'com.apple.NSEventThread'
    frame #0: 0x00007ff80d07596a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x00007ff80d075cd8 libsystem_kernel.dylib`mach_msg + 56
    frame #2: 0x00007ff80d17929d CoreFoundation`__CFRunLoopServiceMachPort + 319
    frame #3: 0x00007ff80d177928 CoreFoundation`__CFRunLoopRun + 1276
    frame #4: 0x00007ff80d176d6c CoreFoundation`CFRunLoopRunSpecific + 562
    frame #5: 0x00007ff80fd1f98e AppKit`_NSEventThread + 132
    frame #6: 0x00007ff80d0b24e1 libsystem_pthread.dylib`_pthread_start + 125
    frame #7: 0x00007ff80d0adf6b libsystem_pthread.dylib`thread_start + 15
  thread #5
    frame #0: 0x00007ff80d07704a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x00007ff80d0af034 libsystem_pthread.dylib`_pthread_wqthread + 426
    frame #2: 0x00007ff80d0adf57 libsystem_pthread.dylib`start_wqthread + 15
(lldb) ^D

-- 
wbr, Kirill

bug#51336: 29.0.50; Application not responding

[Alan Third]

package emacs
merge 51336 67694
thankyou

On Fri, Jan 12, 2024 at 05:31:49PM +0100, Kirill Korinsky wrote:
> Emacs was frozen (UI) and hasn't response to any command. Before that it had
> happened I'd resized a window.
> 
> I attach and de-attach external screen quite often and it triggers the resize.
> 
> So, when it was frozen I've attached via lldb and get stack traces bellow.
> 
> It is reproducable, not each resize but often enough.
> 
> When it frozen, I need to kill it, otherwise it absolutle useless.
> 
> And this stack trace was obtained from local root d9462e24a967e32d550ee886b5150f0cc78358f6
> 
> (lldb) bt all
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
>   * frame #0: 0x00007ff80d07596a libsystem_kernel.dylib`mach_msg_trap + 10
>     frame #1: 0x00007ff80d075cd8 libsystem_kernel.dylib`mach_msg + 56
>     frame #2: 0x00007ff80d17929d CoreFoundation`__CFRunLoopServiceMachPort + 319
>     frame #3: 0x00007ff80d177928 CoreFoundation`__CFRunLoopRun + 1276
>     frame #4: 0x00007ff80d176d6c CoreFoundation`CFRunLoopRunSpecific + 562
>     frame #5: 0x00007ff815e245e6 HIToolbox`RunCurrentEventLoopInMode + 292
>     frame #6: 0x00007ff815e2434a HIToolbox`ReceiveNextEventCommon + 594
>     frame #7: 0x00007ff815e240e5 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 70
>     frame #8: 0x00007ff80fbb1f6d AppKit`_DPSNextEvent + 927
>     frame #9: 0x00007ff80fbb062a AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1394
>     frame #10: 0x00007ff80fba2cd9 AppKit`-[NSApplication run] + 586
>     frame #11: 0x0000000104b2449c Emacs`-[EmacsApp run] + 317

OK, I think this is the same as bug#67694, so I'll merge them.

I think we need to revert 6acb3c5b05a7b9fb32a5336e1bb740f527571ae9 as
discussed in that other bug report and re-open bug#65843, if we can.

Unless anyone else has a better idea.
-- 
Alan Third

bug#51336: 29.0.50; Application not responding

[Eli Zaretskii]

> Date: Fri, 12 Jan 2024 17:22:54 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, stefankangas@gmail.com,
> 	51336@debbugs.gnu.org
> 
> > * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
> >   * frame #0: 0x00007ff80d07596a libsystem_kernel.dylib`mach_msg_trap + 10
> >     frame #1: 0x00007ff80d075cd8 libsystem_kernel.dylib`mach_msg + 56
> >     frame #2: 0x00007ff80d17929d CoreFoundation`__CFRunLoopServiceMachPort + 319
> >     frame #3: 0x00007ff80d177928 CoreFoundation`__CFRunLoopRun + 1276
> >     frame #4: 0x00007ff80d176d6c CoreFoundation`CFRunLoopRunSpecific + 562
> >     frame #5: 0x00007ff815e245e6 HIToolbox`RunCurrentEventLoopInMode + 292
> >     frame #6: 0x00007ff815e2434a HIToolbox`ReceiveNextEventCommon + 594
> >     frame #7: 0x00007ff815e240e5 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 70
> >     frame #8: 0x00007ff80fbb1f6d AppKit`_DPSNextEvent + 927
> >     frame #9: 0x00007ff80fbb062a AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1394
> >     frame #10: 0x00007ff80fba2cd9 AppKit`-[NSApplication run] + 586
> >     frame #11: 0x0000000104b2449c Emacs`-[EmacsApp run] + 317
> 
> OK, I think this is the same as bug#67694, so I'll merge them.
> 
> I think we need to revert 6acb3c5b05a7b9fb32a5336e1bb740f527571ae9 as
> discussed in that other bug report and re-open bug#65843, if we can.

I'm confused: 6acb3c5b05a was installed on master, not on the
emacs-29 branch.  AFAICT, Emacs 29 still has the code which that
commit removed.  And yet the bug report is for Emacs 29(?).  Am I
missing something?

bug#51336: 29.0.50; Application not responding

[Alan Third]

On Fri, Jan 12, 2024 at 08:14:18PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 12 Jan 2024 17:22:54 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: Eli Zaretskii <eliz@gnu.org>, stefankangas@gmail.com,
> > 	51336@debbugs.gnu.org
> > 
> > > * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
> > >   * frame #0: 0x00007ff80d07596a libsystem_kernel.dylib`mach_msg_trap + 10
> > >     frame #1: 0x00007ff80d075cd8 libsystem_kernel.dylib`mach_msg + 56
> > >     frame #2: 0x00007ff80d17929d CoreFoundation`__CFRunLoopServiceMachPort + 319
> > >     frame #3: 0x00007ff80d177928 CoreFoundation`__CFRunLoopRun + 1276
> > >     frame #4: 0x00007ff80d176d6c CoreFoundation`CFRunLoopRunSpecific + 562
> > >     frame #5: 0x00007ff815e245e6 HIToolbox`RunCurrentEventLoopInMode + 292
> > >     frame #6: 0x00007ff815e2434a HIToolbox`ReceiveNextEventCommon + 594
> > >     frame #7: 0x00007ff815e240e5 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 70
> > >     frame #8: 0x00007ff80fbb1f6d AppKit`_DPSNextEvent + 927
> > >     frame #9: 0x00007ff80fbb062a AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1394
> > >     frame #10: 0x00007ff80fba2cd9 AppKit`-[NSApplication run] + 586
> > >     frame #11: 0x0000000104b2449c Emacs`-[EmacsApp run] + 317
> > 
> > OK, I think this is the same as bug#67694, so I'll merge them.
> > 
> > I think we need to revert 6acb3c5b05a7b9fb32a5336e1bb740f527571ae9 as
> > discussed in that other bug report and re-open bug#65843, if we can.
> 
> I'm confused: 6acb3c5b05a was installed on master, not on the
> emacs-29 branch.  AFAICT, Emacs 29 still has the code which that
> commit removed.  And yet the bug report is for Emacs 29(?).  Am I
> missing something?

Kirill specified commit d9462e24a967e32d550ee886b5150f0cc78358f6 which
is, I think, in the master branch.

TBH, I'm not sure what's going on with this bug report, but I'm sure
the current hang is the same as the hang in the other bug report.
Unless I've misunderstood.
-- 
Alan Third

bug#51336: 29.0.50; Application not responding

[Kirill Korinsky]

Greetings,

On Fri, 12 Jan 2024 19:31:53 +0100,
Alan Third wrote:
>
> On Fri, Jan 12, 2024 at 08:14:18PM +0200, Eli Zaretskii wrote:
> >
> > I'm confused: 6acb3c5b05a was installed on master, not on the
> > emacs-29 branch.  AFAICT, Emacs 29 still has the code which that
> > commit removed.  And yet the bug report is for Emacs 29(?).  Am I
> > missing something?
>
> Kirill specified commit d9462e24a967e32d550ee886b5150f0cc78358f6 which
> is, I think, in the master branch.

Yes, I usually runs on something from master which I pick each months or so.

All my picks usually is distributed as `emacs-app-devel` in MacPorts.

> TBH, I'm not sure what's going on with this bug report, but I'm sure
> the current hang is the same as the hang in the other bug report.
> Unless I've misunderstood.

I've made some research in my mail archive and was able to track.

Somewhen before Emacs 29 I've encountered a crash which was reproted as 50641

After it was fixed 50534 had appeared, which also was fixed.

And after this two fixed I've start to seen on near the same setup this issue.

Before switch d9462e24a967e32d550ee886b5150f0cc78358f6 I've used
e32c57ed4d36c5c0302eeb409f96ce9155b545ea for a while and it's behave "classic"
for this bug.

Classic behaviour when I've clicked on Emacs icon inside docker by right click
and the first item on this list "Application not responding".

Sometimes Emacs freezes, but it was not that often.

I really thought that the root cause is magit with MacPorts repository, which
had used huge sqlite DB for keep all PRs.

Anyway, that file were removed and for week I haven't used it => so, it innocent.

Before that I've upgrade to d9462e24a967e32d550ee886b5150f0cc78358f6 and the
hell is started.

The hell that I kill emacs a few times per day because it's frozen completley.

During writing this email (~10 minutes?) it had frozen for a few seconds with
logs like this in *Message* buffer:

Error during redisplay: (jit-lock-function 626) signaled (args-out-of-range "" 0)
Error during redisplay: (jit-lock-function 627) signaled (args-out-of-range "" 0)
Error during redisplay: (jit-lock-function 633) signaled (args-out-of-range "" 0)
Error during redisplay: (jit-lock-function 674) signaled (args-out-of-range "" 0)
Error during redisplay: (jit-lock-function 675) signaled (args-out-of-range "" 0)
Error during redisplay: (jit-lock-function 682) signaled (args-out-of-range "" 0)
Error during redisplay: (jit-lock-function 686) signaled (args-out-of-range "" 0)
Error during redisplay: (jit-lock-function 687) signaled (args-out-of-range "" 0)
Error during redisplay: (jit-lock-function 688) signaled (args-out-of-range "" 0)
Error during redisplay: (jit-lock-function 687) signaled (args-out-of-range "" 0)
Error during redisplay: (jit-lock-function 696) signaled (args-out-of-range "" 0)

And once it was completley frozen with similar stacktrace via lldb, and I must
to restart it, and continue this draft.

My usual rutine is keep it runing, I'm using a few (like 5) virtual desktops
which and some of them has emacs frames.

Sometimes I attach and de-attach external display with much largest resolution,
and close the lid on laptop => everything moves to largest screen and resized.

--
wbr, Kirill

bug#51336: 29.0.50; Application not responding

[Eli Zaretskii]

> Date: Sat, 13 Jan 2024 00:53:12 +0100
> From: Kirill Korinsky <kirill@korins.ky>
> 
> > > I'm confused: 6acb3c5b05a was installed on master, not on the
> > > emacs-29 branch.  AFAICT, Emacs 29 still has the code which that
> > > commit removed.  And yet the bug report is for Emacs 29(?).  Am I
> > > missing something?
> >
> > Kirill specified commit d9462e24a967e32d550ee886b5150f0cc78358f6 which
> > is, I think, in the master branch.
> 
> Yes, I usually runs on something from master which I pick each months or so.

So the Emacs version where you see these freezes is 30.0.50, not
29.0.50 (or any other 29.x.y)?

> During writing this email (~10 minutes?) it had frozen for a few seconds with
> logs like this in *Message* buffer:
> 
> Error during redisplay: (jit-lock-function 626) signaled (args-out-of-range "" 0)
> Error during redisplay: (jit-lock-function 627) signaled (args-out-of-range "" 0)
> Error during redisplay: (jit-lock-function 633) signaled (args-out-of-range "" 0)
> Error during redisplay: (jit-lock-function 674) signaled (args-out-of-range "" 0)
> Error during redisplay: (jit-lock-function 675) signaled (args-out-of-range "" 0)
> Error during redisplay: (jit-lock-function 682) signaled (args-out-of-range "" 0)
> Error during redisplay: (jit-lock-function 686) signaled (args-out-of-range "" 0)
> Error during redisplay: (jit-lock-function 687) signaled (args-out-of-range "" 0)
> Error during redisplay: (jit-lock-function 688) signaled (args-out-of-range "" 0)
> Error during redisplay: (jit-lock-function 687) signaled (args-out-of-range "" 0)
> Error during redisplay: (jit-lock-function 696) signaled (args-out-of-range "" 0)

I would suggest to find out which Lisp code causes these messages.
What mode do you use to type email, and what customizations of that
mode do you have?

Alan, is there something special in how redisplay on NS handles Lisp
errors which happen in JIT font-lock?  On other platforms, such errors
are caught and ignored, resulting only in messages in *Messages*, they
never cause any freezes, except perhaps for short time intervals (if
the errors are generated at high frequency, or maybe continuously).

bug#51336: 29.0.50; Application not responding

[Kirill Korinsky]

Greetings,

Seems I've cleaned everything from different noise and was able to reproduce
the real issue.

I not sure that it is realted to this bug, or it is another things, but I
suggest to continue here.

I'm using doom emacs with some minor tracking and it requires some time (~2
seconds) to load everything with enabled native compilation.

If resize the window on that moment, after load it doesn't react on keyboar.

But it reacts on mouse pointer.

So, I may move mouse pointer and UI reacts to it, but no key binding.

-- 
wbr, Kirill

bug#51336: 29.0.50; Application not responding

[Eli Zaretskii]

> Date: Sat, 13 Jan 2024 23:41:43 +0100
> From: Kirill Korinsky <kirill@korins.ky>
> Cc: alan@idiocy.org,
> 	stefankangas@gmail.com,
> 	51336@debbugs.gnu.org
> 
> Seems I've cleaned everything from different noise and was able to reproduce
> the real issue.
> 
> I not sure that it is realted to this bug, or it is another things, but I
> suggest to continue here.
> 
> I'm using doom emacs with some minor tracking and it requires some time (~2
> seconds) to load everything with enabled native compilation.
> 
> If resize the window on that moment, after load it doesn't react on keyboar.
> 
> But it reacts on mouse pointer.
> 
> So, I may move mouse pointer and UI reacts to it, but no key binding.

Thanks.

Alan, any ideas or suggestions?

bug#51336: 29.0.50; Application not responding

[Kirill A. Korinsky]

On Sat, 20 Jan 2024 10:23:58 +0100,
Eli Zaretskii wrote:
> 
> > I'm using doom emacs with some minor tracking and it requires some time (~2
> > seconds) to load everything with enabled native compilation.
> > 
> > If resize the window on that moment, after load it doesn't react on keyboar.
> > So, I may move mouse pointer and UI reacts to it, but no key binding.
> 
> Alan, any ideas or suggestions?

If it helps, I found some corelation with system overload which is cause by
kernel_task I assume.

When I run something heavy on this machine, the kernek_task starts increase
number of processes and consume some CPU[1], which leads to irresponsible
system.

Unfortently it "degradates" and after I stop doing so, the system still less
responsible than it was before that throtling.

After a number of that cycle when it degradate enough, I able to reporduce the
issue with "no key binding" often enough.

But after reboot this issue almost dissapear, and to reprodice it I need to
restart emacs a lot of time. I haven't count it, but it feels like dozen.

And before reboot on the same machine I was able to reproduce it almost each
start. Frankly speaking I need to kill it a few times, before it has started
in the way that it can react to keyboard.

I've tried to run with emacs -Q, but it loads too fast and I won't able to
reproduce that issue on any state of my laptop.

Footnotes:
[1]  https://support.apple.com/en-us/102172

-- 
wbr, Kirill

bug#51336: 29.0.50; Application not responding

[Kirill A. Korinsky]

I'd like to add one more complete freez.

I've used icon in the dock to open a new frame (4th or 5th I guess), where I
open a file at /tmp. authorized_keys from some servers. It is less than 10kb and
doesn't use any mode to be edited.

I've start to scroll it and emacs was frozen.

No response to emacsclient, nor any another frame.

When I've attached to this process by lldb I was able to obtain stacks:

(lldb) bt all
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007ff8100a196a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x00007ff8100a1cd8 libsystem_kernel.dylib`mach_msg + 56
    frame #2: 0x00007ff8101a529d CoreFoundation`__CFRunLoopServiceMachPort + 319
    frame #3: 0x00007ff8101a3928 CoreFoundation`__CFRunLoopRun + 1276
    frame #4: 0x00007ff8101a2d6c CoreFoundation`CFRunLoopRunSpecific + 562
    frame #5: 0x00007ff818e505e6 HIToolbox`RunCurrentEventLoopInMode + 292
    frame #6: 0x00007ff818e5034a HIToolbox`ReceiveNextEventCommon + 594
    frame #7: 0x00007ff818e500e5 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 70
    frame #8: 0x00007ff812bddf6d AppKit`_DPSNextEvent + 927
    frame #9: 0x00007ff812bdc62a AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1394
    frame #10: 0x00007ff812bcecd9 AppKit`-[NSApplication run] + 586
    frame #11: 0x00000001001f44a8 Emacs`-[EmacsApp run] + 317
    frame #12: 0x00000001002061d6 Emacs`ns_read_socket_1 + 553
    frame #13: 0x00000001000e5119 Emacs`gobble_input + 243
    frame #14: 0x00000001000e39d6 Emacs`get_input_pending + 97
    frame #15: 0x00000001000e1d16 Emacs`detect_input_pending_run_timers + 46
    frame #16: 0x00000001001ae0bb Emacs`wait_reading_process_output + 4372
    frame #17: 0x0000000100014294 Emacs`sit_for + 436
    frame #18: 0x00000001000df07b Emacs`read_char + 7016
    frame #19: 0x00000001000db75d Emacs`read_key_sequence + 1247
    frame #20: 0x00000001000d9d1c Emacs`command_loop_1 + 754
    frame #21: 0x00000001001591a6 Emacs`internal_condition_case + 87
    frame #22: 0x00000001000d9a18 Emacs`command_loop_2 + 41
    frame #23: 0x0000000100158ad2 Emacs`internal_catch + 81
    frame #24: 0x000000010022ee4f Emacs`command_loop.cold.1 + 72
    frame #25: 0x00000001000d946f Emacs`command_loop + 132
    frame #26: 0x00000001000d935c Emacs`recursive_edit_1 + 142
    frame #27: 0x00000001000d955a Emacs`Frecursive_edit + 208
    frame #28: 0x00000001000d88ec Emacs`main + 8278
    frame #29: 0x00000001027cc52e dyld`start + 462
  thread #2, name = 'gmain'
    frame #0: 0x00007ff8100a9d4a libsystem_kernel.dylib`__select + 10
    frame #1: 0x000000010172f9f0 libglib-2.0.0.dylib`g_poll + 505
    frame #2: 0x0000000101721049 libglib-2.0.0.dylib`g_main_context_iterate_unlocked + 297
    frame #3: 0x00000001017210fc libglib-2.0.0.dylib`g_main_context_iteration + 55
    frame #4: 0x00000001017220e7 libglib-2.0.0.dylib`glib_worker_main + 30
    frame #5: 0x0000000101746ce7 libglib-2.0.0.dylib`g_thread_proxy + 66
    frame #6: 0x00007ff8100de4e1 libsystem_pthread.dylib`_pthread_start + 125
    frame #7: 0x00007ff8100d9f6b libsystem_pthread.dylib`thread_start + 15
  thread #3
    frame #0: 0x00007ff8100a6456 libsystem_kernel.dylib`__pselect + 10
    frame #1: 0x00007ff8100a6373 libsystem_kernel.dylib`pselect$DARWIN_EXTSN + 42
    frame #2: 0x00000001001f5359 Emacs`-[EmacsApp fd_handler:] + 201
    frame #3: 0x00007ff810ffa964 Foundation`__NSThread__start__ + 1009
    frame #4: 0x00007ff8100de4e1 libsystem_pthread.dylib`_pthread_start + 125
    frame #5: 0x00007ff8100d9f6b libsystem_pthread.dylib`thread_start + 15
  thread #4, name = 'com.apple.NSEventThread'
    frame #0: 0x00007ff8100a196a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x00007ff8100a1cd8 libsystem_kernel.dylib`mach_msg + 56
    frame #2: 0x00007ff8101a529d CoreFoundation`__CFRunLoopServiceMachPort + 319
    frame #3: 0x00007ff8101a3928 CoreFoundation`__CFRunLoopRun + 1276
    frame #4: 0x00007ff8101a2d6c CoreFoundation`CFRunLoopRunSpecific + 562
    frame #5: 0x00007ff812d4b98e AppKit`_NSEventThread + 132
    frame #6: 0x00007ff8100de4e1 libsystem_pthread.dylib`_pthread_start + 125
    frame #7: 0x00007ff8100d9f6b libsystem_pthread.dylib`thread_start + 15
  thread #5
    frame #0: 0x00007ff8100a304a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x00007ff8100db034 libsystem_pthread.dylib`_pthread_wqthread + 426
    frame #2: 0x00007ff8100d9f57 libsystem_pthread.dylib`start_wqthread + 15
(lldb)

Right now I'm running emacs which was build from 2c887f497c723c2397888e2f406faa4de3a8208a

-- 
wbr, Kirill