bug#56967: 29.0.50; Frequent crashes under Wayland

bug#56967: 29.0.50; Frequent crashes under Wayland

[Bjoern Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

To trigger the bug there needs to be some usage so I'm not sure how to
trigger the bug with ~emacs -Q~.
However Emacs just stops usually, sometimes emacs freezes for a few sec 
before.
I start emacs as a systemd --user service, systemd reports that emacs
stops like this:
emacs.service: Main process exited, code=exited, status=1/FAILURE

No other output or crashdump is there.

It happens after a time, sometimes it fails after hours sometimes it fails 
after 10 minues.

In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, 
cairo version 1.17.6)
 of 2022-08-03 built on 224768
Repository revision: 21afc26d4df6bae35ba032d4b6b03fb7fb2bf1b3
Repository branch: master
System Description: Arch Linux

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
 --with-modules --with-libotf --without-gconf --with-libsystemd
 --enable-link-time-optimization --with-native-compilation
 --with-xinput2 --with-pgtk --without-xaw3d --with-sound=alsa
 --without-gpm '--program-transform-name=s/\([ec]tags\)/\1.emacs/'
 'CFLAGS=-march=x86-64 -mtune=native -O2 -pipe -fno-plt -fexceptions
 -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
 -fstack-clash-protection -fcf-protection -flto=auto'
 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -flto=auto'
 'CXXFLAGS=-march=x86-64 -mtune=native -O2 -pipe -fno-plt -fexceptions
 -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
 -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS
 -flto=auto''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS WEBP XIM GTK3 ZLIB

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

Major mode: Circe Server

Minor modes in effect:
  guess-language-mode: t
  cursor-intangible-mode: t
  which-key-mode: t
  beacon-mode: t
  savehist-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  tracking-mode: t
  flyspell-mode: t
  global-edit-server-edit-mode: t
  desktop-save-mode: t
  global-so-long-mode: t
  change-cursor-mode: t
  recentf-mode: t
  helm-mode: t
  helm-minibuffer-history-mode: t
  helm-autoresize-mode: t
  helm--remap-mouse-mode: t
  async-bytecomp-package-mode: t
  mode-icons-mode: t
  global-emojify-mode: t
  emojify-mode: t
  electric-pair-mode: t
  editorconfig-mode: t
  projectile-mode: t
  shell-dirtrack-mode: t
  flycheck-color-mode-line-mode: t
  global-flycheck-mode: t
  flycheck-mode: t
  override-global-mode: t
  global-company-mode: t
  company-mode: t
  save-place-mode: t
  gcmh-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-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
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/bidar/.emacs.d/elpa/auto-complete-20211231.1808/auto-complete hides /
home/bidar/.emacs.d/elpa/auto-complete-20220105.439/auto-complete
/home/bidar/.emacs.d/elpa/auto-complete-20211231.1808/auto-complete-pkg hides 
/home/bidar/.emacs.d/elpa/auto-complete-20220105.439/auto-complete-pkg
/home/bidar/.emacs.d/elpa/auto-complete-20211231.1808/auto-complete-config 
hides /home/bidar/.emacs.d/elpa/auto-complete-20220105.439/auto-complete-
config
/home/bidar/.emacs.d/elpa/auto-complete-20211231.1808/auto-complete-autoloads 
hides /home/bidar/.emacs.d/elpa/auto-complete-20220105.439/auto-complete-
autoloads
/home/bidar/.emacs.d/elpa/avy-20201226.1734/avy hides /home/bidar/.emacs.d/
elpa/avy-20220102.805/avy
/home/bidar/.emacs.d/elpa/avy-20201226.1734/avy-pkg hides /home/
bidar/.emacs.d/elpa/avy-20220102.805/avy-pkg
/home/bidar/.emacs.d/elpa/avy-20201226.1734/avy-autoloads hides /home/
bidar/.emacs.d/elpa/avy-20220102.805/avy-autoloads
/home/bidar/.emacs.d/elpa/cfrs-20211013.1802/cfrs hides /home/bidar/.emacs.d/
elpa/cfrs-20220129.1149/cfrs
/home/bidar/.emacs.d/elpa/cfrs-20211013.1802/cfrs-pkg hides /home/
bidar/.emacs.d/elpa/cfrs-20220129.1149/cfrs-pkg
/home/bidar/.emacs.d/elpa/cfrs-20211013.1802/cfrs-autoloads hides /home/
bidar/.emacs.d/elpa/cfrs-20220129.1149/cfrs-autoloads
/home/bidar/.emacs.d/elpa/cmake-font-lock-20210103.1558/cmake-font-lock hides 
/home/bidar/.emacs.d/elpa/cmake-font-lock-20211224.2006/cmake-font-lock
/home/bidar/.emacs.d/elpa/cmake-font-lock-20210103.1558/cmake-font-lock-pkg 
hides /home/bidar/.emacs.d/elpa/cmake-font-lock-20211224.2006/cmake-font-lock-
pkg
/home/bidar/.emacs.d/elpa/cmake-font-lock-20210103.1558/cmake-font-lock-
autoloads hides /home/bidar/.emacs.d/elpa/cmake-font-lock-20211224.2006/cmake-
font-lock-autoloads
/home/bidar/.emacs.d/elpa/hydra-20201115.1055/hydra hides /home/
bidar/.emacs.d/elpa/hydra-20220102.803/hydra
/home/bidar/.emacs.d/elpa/hydra-20201115.1055/hydra-pkg hides /home/
bidar/.emacs.d/elpa/hydra-20220102.803/hydra-pkg
/home/bidar/.emacs.d/elpa/hydra-20201115.1055/hydra-ox hides /home/
bidar/.emacs.d/elpa/hydra-20220102.803/hydra-ox
/home/bidar/.emacs.d/elpa/hydra-20201115.1055/hydra-examples hides /home/
bidar/.emacs.d/elpa/hydra-20220102.803/hydra-examples
/home/bidar/.emacs.d/elpa/hydra-20201115.1055/hydra-autoloads hides /home/
bidar/.emacs.d/elpa/hydra-20220102.803/hydra-autoloads
/home/bidar/.emacs.d/elpa/irony-20210605.1018/irony hides /home/
bidar/.emacs.d/elpa/irony-20220110.849/irony
/home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-snippet hides /home/
bidar/.emacs.d/elpa/irony-20220110.849/irony-snippet
/home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-pkg hides /home/
bidar/.emacs.d/elpa/irony-20220110.849/irony-pkg
/home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-iotask hides /home/
bidar/.emacs.d/elpa/irony-20220110.849/irony-iotask
/home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-diagnostics hides /home/
bidar/.emacs.d/elpa/irony-20220110.849/irony-diagnostics
/home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-completion hides /home/
bidar/.emacs.d/elpa/irony-20220110.849/irony-completion
/home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-cdb hides /home/
bidar/.emacs.d/elpa/irony-20220110.849/irony-cdb
/home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-cdb-libclang hides /home/
bidar/.emacs.d/elpa/irony-20220110.849/irony-cdb-libclang
/home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-cdb-json hides /home/
bidar/.emacs.d/elpa/irony-20220110.849/irony-cdb-json
/home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-cdb-clang-complete hides /
home/bidar/.emacs.d/elpa/irony-20220110.849/irony-cdb-clang-complete
/home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-autoloads hides /home/
bidar/.emacs.d/elpa/irony-20220110.849/irony-autoloads
~/.emacs.d/lisp/ox-koma-letter hides /home/bidar/.emacs.d/elpa/org-9.5.4/ox-
koma-letter
~/.emacs.d/lisp/ox-groff hides /home/bidar/.emacs.d/elpa/org-contrib-0.4/ox-
groff
/home/bidar/.emacs.d/elpa/org-9.5.4/ox hides /home/bidar/.emacs.d/elpa/org-
plus-contrib-20210929/ox
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-texinfo hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ox-texinfo
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ox-taskjuggler hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/ox-taskjuggler
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ox-s5 hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ox-s5
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-publish hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ox-publish
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-org hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ox-org
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-odt hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ox-odt
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-md hides /home/bidar/.emacs.d/elpa/org-
plus-contrib-20210929/ox-md
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-man hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ox-man
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-latex hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ox-latex
~/.emacs.d/lisp/ox-koma-letter hides /home/bidar/.emacs.d/elpa/org-plus-
contrib-20210929/ox-koma-letter
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-icalendar hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ox-icalendar
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-html hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ox-html
~/.emacs.d/lisp/ox-groff hides /home/bidar/.emacs.d/elpa/org-plus-
contrib-20210929/ox-groff
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ox-freemind hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/ox-freemind
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ox-extra hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ox-extra
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ox-deck hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ox-deck
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ox-confluence hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/ox-confluence
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ox-bibtex hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/ox-bibtex
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-beamer hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ox-beamer
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-ascii hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ox-ascii
/home/bidar/.emacs.d/elpa/org-contrib-0.4/orgtbl-sqlinsert hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/orgtbl-sqlinsert
/home/bidar/.emacs.d/elpa/org-9.5.4/org hides /home/bidar/.emacs.d/elpa/org-
plus-contrib-20210929/org
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-wikinodes hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-wikinodes
/home/bidar/.emacs.d/elpa/org-9.5.4/org-version hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-version
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-track hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-track
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-toc hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-toc
/home/bidar/.emacs.d/elpa/org-9.5.4/org-timer hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/org-timer
/home/bidar/.emacs.d/elpa/org-9.5.4/org-tempo hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/org-tempo
/home/bidar/.emacs.d/elpa/org-9.5.4/org-table hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/org-table
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-sudoku hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-sudoku
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-static-mathjax hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-static-mathjax
/home/bidar/.emacs.d/elpa/org-9.5.4/org-src hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/org-src
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-secretary hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-secretary
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-screenshot hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-screenshot
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-screen hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-screen
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-registry hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-registry
/home/bidar/.emacs.d/elpa/org-9.5.4/org-refile hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-refile
/home/bidar/.emacs.d/elpa/org-9.5.4/org-protocol hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-protocol
/home/bidar/.emacs.d/elpa/org-9.5.4/org-plot hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/org-plot
/home/bidar/.emacs.d/elpa/org-9.5.4/org-pcomplete hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-pcomplete
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-panel hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-panel
/home/bidar/.emacs.d/elpa/org-9.5.4/org-num hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/org-num
/home/bidar/.emacs.d/elpa/org-9.5.4/org-mouse hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/org-mouse
/home/bidar/.emacs.d/elpa/org-9.5.4/org-mobile hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-mobile
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-mairix hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-mairix
/home/bidar/.emacs.d/elpa/org-9.5.4/org-macs hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/org-macs
/home/bidar/.emacs.d/elpa/org-9.5.4/org-macro hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/org-macro
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-mac-iCal hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-mac-iCal
/home/bidar/.emacs.d/elpa/org-9.5.4/org-loaddefs hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-loaddefs
/home/bidar/.emacs.d/elpa/org-9.5.4/org-list hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/org-list
/home/bidar/.emacs.d/elpa/org-9.5.4/org-lint hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/org-lint
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-license hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-license
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-learn hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-learn
/home/bidar/.emacs.d/elpa/org-9.5.4/org-keys hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/org-keys
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-invoice hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-invoice
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-interactive-query hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-interactive-query
/home/bidar/.emacs.d/elpa/org-9.5.4/org-inlinetask hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-inlinetask
/home/bidar/.emacs.d/elpa/org-9.5.4/org-indent hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-indent
/home/bidar/.emacs.d/elpa/org-9.5.4/org-id hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/org-id
/home/bidar/.emacs.d/elpa/org-9.5.4/org-habit hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/org-habit
/home/bidar/.emacs.d/elpa/org-9.5.4/org-goto hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/org-goto
/home/bidar/.emacs.d/elpa/org-9.5.4/org-footnote hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-footnote
/home/bidar/.emacs.d/elpa/org-9.5.4/org-feed hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/org-feed
/home/bidar/.emacs.d/elpa/org-9.5.4/org-faces hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/org-faces
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-expiry hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-expiry
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-eval hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-eval
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-eval-light hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-eval-light
/home/bidar/.emacs.d/elpa/org-9.5.4/org-entities hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-entities
/home/bidar/.emacs.d/elpa/org-9.5.4/org-element hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-element
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-eldoc hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-eldoc
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-effectiveness hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-effectiveness
/home/bidar/.emacs.d/elpa/org-9.5.4/org-duration hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-duration
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-depend hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-depend
/home/bidar/.emacs.d/elpa/org-9.5.4/org-datetree hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-datetree
/home/bidar/.emacs.d/elpa/org-9.5.4/org-ctags hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/org-ctags
/home/bidar/.emacs.d/elpa/org-9.5.4/org-crypt hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/org-crypt
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-contribdir hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-contribdir
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-contrib hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-contrib
/home/bidar/.emacs.d/elpa/org-9.5.4/org-compat hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-compat
/home/bidar/.emacs.d/elpa/org-9.5.4/org-colview hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-colview
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-collector hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-collector
/home/bidar/.emacs.d/elpa/org-9.5.4/org-clock hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/org-clock
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-choose hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-choose
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-checklist hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-checklist
/home/bidar/.emacs.d/elpa/org-9.5.4/org-capture hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-capture
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-bibtex-extras hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-bibtex-extras
/home/bidar/.emacs.d/elpa/org-9.5.4/org-attach hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-attach
/home/bidar/.emacs.d/elpa/org-9.5.4/org-attach-git hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-attach-git
/home/bidar/.emacs.d/elpa/org-9.5.4/org-archive hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-archive
/home/bidar/.emacs.d/elpa/org-contrib-0.4/org-annotate-file hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-annotate-file
/home/bidar/.emacs.d/elpa/org-9.5.4/org-agenda hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/org-agenda
/home/bidar/.emacs.d/elpa/org-9.5.4/ol hides /home/bidar/.emacs.d/elpa/org-
plus-contrib-20210929/ol
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ol-wl hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ol-wl
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-w3m hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ol-w3m
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ol-vm hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ol-vm
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-rmail hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ol-rmail
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-mhe hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ol-mhe
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ol-mew hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ol-mew
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-man hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ol-man
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-irc hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ol-irc
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-info hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ol-info
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-gnus hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ol-gnus
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ol-git-link hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/ol-git-link
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-eww hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ol-eww
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-eshell hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ol-eshell
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ol-elisp-symbol hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/ol-elisp-symbol
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-doi hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ol-doi
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-docview hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ol-docview
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ol-bookmark hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/ol-bookmark
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-bibtex hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ol-bibtex
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-bbdb hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ol-bbdb
/home/bidar/.emacs.d/elpa/org-9.5.4/oc hides /home/bidar/.emacs.d/elpa/org-
plus-contrib-20210929/oc
/home/bidar/.emacs.d/elpa/org-9.5.4/oc-natbib hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/oc-natbib
/home/bidar/.emacs.d/elpa/org-9.5.4/oc-csl hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/oc-csl
/home/bidar/.emacs.d/elpa/org-9.5.4/oc-biblatex hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/oc-biblatex
/home/bidar/.emacs.d/elpa/org-9.5.4/oc-basic hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/oc-basic
/home/bidar/.emacs.d/elpa/org-9.5.4/ob hides /home/bidar/.emacs.d/elpa/org-
plus-contrib-20210929/ob
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-vbnet hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-vbnet
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-vala hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-vala
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-tcl hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-tcl
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-tangle hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-tangle
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-table hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-table
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-stata hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-stata
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-sqlite hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-sqlite
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-sql hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-sql
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-spice hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-spice
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-shen hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-shen
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-shell hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-shell
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-sed hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-sed
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-screen hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-screen
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-scheme hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-scheme
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-sass hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-sass
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-ruby hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-ruby
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-ref hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-ref
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-python hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-python
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-processing hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-processing
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-plantuml hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-plantuml
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-picolisp hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/ob-picolisp
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-perl hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-perl
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-oz hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-oz
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-org hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-org
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-octave hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-octave
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-ocaml hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-ocaml
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-mscgen hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/ob-mscgen
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-maxima hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-maxima
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-matlab hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-matlab
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-mathomatic hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/ob-mathomatic
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-makefile hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-makefile
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-lua hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-lua
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-lob hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-lob
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-lisp hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-lisp
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-lilypond hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-lilypond
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-ledger hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/ob-ledger
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-latex hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-latex
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-julia hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-julia
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-js hides /home/bidar/.emacs.d/elpa/org-
plus-contrib-20210929/ob-js
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-java hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-java
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-io hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-io
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-hledger hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/ob-hledger
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-haskell hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-haskell
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-groovy hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-groovy
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-gnuplot hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-gnuplot
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-fortran hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-fortran
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-forth hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-forth
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-fomus hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-fomus
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-exp hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-exp
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-eval hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-eval
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-eukleides hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/ob-eukleides
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-eshell hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-eshell
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-emacs-lisp hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-emacs-lisp
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-ebnf hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-ebnf
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-dot hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-dot
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-ditaa hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-ditaa
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-css hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-css
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-csharp hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/ob-csharp
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-core hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-core
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-coq hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-coq
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-comint hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-comint
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-clojure hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-clojure
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-calc hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-calc
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-awk hides /home/bidar/.emacs.d/elpa/
org-plus-contrib-20210929/ob-awk
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-asymptote hides /home/
bidar/.emacs.d/elpa/org-plus-contrib-20210929/ob-asymptote
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-abc hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-abc
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-R hides /home/bidar/.emacs.d/elpa/org-
plus-contrib-20210929/ob-R
/home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-J hides /home/bidar/.emacs.d/
elpa/org-plus-contrib-20210929/ob-J
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-C hides /home/bidar/.emacs.d/elpa/org-
plus-contrib-20210929/ob-C
/home/bidar/.emacs.d/elpa/org-tree-slide-20211213.1254/org-tree-slide hides /
home/bidar/.emacs.d/elpa/org-tree-slide-20220112.142/org-tree-slide
/home/bidar/.emacs.d/elpa/org-tree-slide-20211213.1254/org-tree-slide-pkg 
hides /home/bidar/.emacs.d/elpa/org-tree-slide-20220112.142/org-tree-slide-pkg
/home/bidar/.emacs.d/elpa/org-tree-slide-20211213.1254/org-tree-slide-
autoloads hides /home/bidar/.emacs.d/elpa/org-tree-slide-20220112.142/org-
tree-slide-autoloads
/home/bidar/.emacs.d/elpa/pfuture-20200425.1357/pfuture hides /home/
bidar/.emacs.d/elpa/pfuture-20211229.1513/pfuture
/home/bidar/.emacs.d/elpa/pfuture-20200425.1357/pfuture-pkg hides /home/
bidar/.emacs.d/elpa/pfuture-20211229.1513/pfuture-pkg
/home/bidar/.emacs.d/elpa/pfuture-20200425.1357/pfuture-autoloads hides /home/
bidar/.emacs.d/elpa/pfuture-20211229.1513/pfuture-autoloads
/home/bidar/.emacs.d/elpa/pfuture-20200425.1357/pfuture hides /home/
bidar/.emacs.d/elpa/pfuture-20220425.1242/pfuture
/home/bidar/.emacs.d/elpa/pfuture-20200425.1357/pfuture-pkg hides /home/
bidar/.emacs.d/elpa/pfuture-20220425.1242/pfuture-pkg
/home/bidar/.emacs.d/elpa/pfuture-20200425.1357/pfuture-autoloads hides /home/
bidar/.emacs.d/elpa/pfuture-20220425.1242/pfuture-autoloads
/home/bidar/.emacs.d/elpa/popup-20210317.138/popup hides /home/bidar/.emacs.d/
elpa/popup-20210625.400/popup
/home/bidar/.emacs.d/elpa/popup-20210317.138/popup-pkg hides /home/
bidar/.emacs.d/elpa/popup-20210625.400/popup-pkg
/home/bidar/.emacs.d/elpa/popup-20210317.138/popup-autoloads hides /home/
bidar/.emacs.d/elpa/popup-20210625.400/popup-autoloads
/home/bidar/.emacs.d/elpa/popup-20210317.138/popup hides /home/bidar/.emacs.d/
elpa/popup-20211231.1823/popup
/home/bidar/.emacs.d/elpa/popup-20210317.138/popup-pkg hides /home/
bidar/.emacs.d/elpa/popup-20211231.1823/popup-pkg
/home/bidar/.emacs.d/elpa/popup-20210317.138/popup-autoloads hides /home/
bidar/.emacs.d/elpa/popup-20211231.1823/popup-autoloads
/home/bidar/.emacs.d/elpa/powerline-20211022.655/powerline hides /home/
bidar/.emacs.d/elpa/powerline-20220122.1904/powerline
/home/bidar/.emacs.d/elpa/powerline-20211022.655/powerline-themes hides /home/
bidar/.emacs.d/elpa/powerline-20220122.1904/powerline-themes
/home/bidar/.emacs.d/elpa/powerline-20211022.655/powerline-separators hides /
home/bidar/.emacs.d/elpa/powerline-20220122.1904/powerline-separators
/home/bidar/.emacs.d/elpa/powerline-20211022.655/powerline-pkg hides /home/
bidar/.emacs.d/elpa/powerline-20220122.1904/powerline-pkg
/home/bidar/.emacs.d/elpa/powerline-20211022.655/powerline-autoloads hides /
home/bidar/.emacs.d/elpa/powerline-20220122.1904/powerline-autoloads
/home/bidar/.emacs.d/elpa/s-20210603.736/s hides /home/bidar/.emacs.d/elpa/
s-20210616.619/s
/home/bidar/.emacs.d/elpa/s-20210603.736/s-pkg hides /home/bidar/.emacs.d/
elpa/s-20210616.619/s-pkg
/home/bidar/.emacs.d/elpa/s-20210603.736/s-autoloads hides /home/
bidar/.emacs.d/elpa/s-20210616.619/s-autoloads
/home/bidar/.emacs.d/elpa/spinner-1.7.3/spinner hides /home/bidar/.emacs.d/
elpa/spinner-1.7.4/spinner
/home/bidar/.emacs.d/elpa/spinner-1.7.3/spinner-pkg hides /home/
bidar/.emacs.d/elpa/spinner-1.7.4/spinner-pkg
/home/bidar/.emacs.d/elpa/spinner-1.7.3/spinner-autoloads hides /home/
bidar/.emacs.d/elpa/spinner-1.7.4/spinner-autoloads
/home/bidar/.emacs.d/elpa/circe-20220526.1206/tracking hides /home/
bidar/.emacs.d/elpa/tracking-20210713.1609/tracking
/home/bidar/.emacs.d/elpa/circe-20220526.1206/shorten hides /home/
bidar/.emacs.d/elpa/tracking-20210713.1609/shorten
/home/bidar/.emacs.d/elpa/xpm-1.0.4/xpm hides /home/bidar/.emacs.d/elpa/
xpm-1.0.5/xpm
/home/bidar/.emacs.d/elpa/xpm-1.0.4/xpm-pkg hides /home/bidar/.emacs.d/elpa/
xpm-1.0.5/xpm-pkg
/home/bidar/.emacs.d/elpa/xpm-1.0.4/xpm-m2z hides /home/bidar/.emacs.d/elpa/
xpm-1.0.5/xpm-m2z
/home/bidar/.emacs.d/elpa/xpm-1.0.4/xpm-autoloads hides /home/bidar/.emacs.d/
elpa/xpm-1.0.5/xpm-autoloads
/home/bidar/.emacs.d/elpa/yaml-mode-20211230.1126/yaml-mode hides /home/
bidar/.emacs.d/elpa/yaml-mode-20220104.1503/yaml-mode
/home/bidar/.emacs.d/elpa/yaml-mode-20211230.1126/yaml-mode-pkg hides /home/
bidar/.emacs.d/elpa/yaml-mode-20220104.1503/yaml-mode-pkg
/home/bidar/.emacs.d/elpa/yaml-mode-20211230.1126/yaml-mode-autoloads hides /
home/bidar/.emacs.d/elpa/yaml-mode-20220104.1503/yaml-mode-autoloads
/home/bidar/.emacs.d/elpa/irony-20210605.1018/irony hides /home/
bidar/.emacs.d/elpa/irony-20210605.1018/server/test/elisp/irony
/home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-iotask hides /home/
bidar/.emacs.d/elpa/irony-20210605.1018/server/test/elisp/irony-iotask
/home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-cdb-json hides /home/
bidar/.emacs.d/elpa/irony-20210605.1018/server/test/elisp/irony-cdb-json
/home/bidar/.emacs.d/elpa/irony-20210605.1018/server/test/elisp/test-config 
hides /home/bidar/.emacs.d/elpa/irony-20220110.849/server/test/elisp/test-
config
/home/bidar/.emacs.d/elpa/irony-20210605.1018/irony hides /home/
bidar/.emacs.d/elpa/irony-20220110.849/server/test/elisp/irony
/home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-iotask hides /home/
bidar/.emacs.d/elpa/irony-20220110.849/server/test/elisp/irony-iotask
/home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-cdb-json hides /home/
bidar/.emacs.d/elpa/irony-20220110.849/server/test/elisp/irony-cdb-json
/home/bidar/.emacs.d/elpa/cmake-mode-20220617.1532/cmake-mode hides /usr/
share/emacs/site-lisp/cmake-mode
/home/bidar/.emacs.d/elpa/libgit-20220620.1118/libgit hides /usr/share/emacs/
site-lisp/libgit
/home/bidar/.emacs.d/elpa/dash-20220608.1931/dash hides /usr/share/emacs/site-
lisp/dash/dash
/home/bidar/.emacs.d/elpa/dash-functional-20210210.1449/dash-functional hides 
/usr/share/emacs/site-lisp/dash/dash-functional
/home/bidar/.emacs.d/elpa/transient-20220717.1713/transient hides /usr/share/
emacs/29.0.50/lisp/transient
/home/bidar/.emacs.d/elpa/org-9.5.4/ox hides /usr/share/emacs/29.0.50/lisp/
org/ox
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-texinfo hides /usr/share/emacs/29.0.50/
lisp/org/ox-texinfo
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-publish hides /usr/share/emacs/29.0.50/
lisp/org/ox-publish
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-org hides /usr/share/emacs/29.0.50/
lisp/org/ox-org
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-odt hides /usr/share/emacs/29.0.50/
lisp/org/ox-odt
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-md hides /usr/share/emacs/29.0.50/lisp/
org/ox-md
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-man hides /usr/share/emacs/29.0.50/
lisp/org/ox-man
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-latex hides /usr/share/emacs/29.0.50/
lisp/org/ox-latex
~/.emacs.d/lisp/ox-koma-letter hides /usr/share/emacs/29.0.50/lisp/org/ox-
koma-letter
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-icalendar hides /usr/share/emacs/
29.0.50/lisp/org/ox-icalendar
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-html hides /usr/share/emacs/29.0.50/
lisp/org/ox-html
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-beamer hides /usr/share/emacs/29.0.50/
lisp/org/ox-beamer
/home/bidar/.emacs.d/elpa/org-9.5.4/ox-ascii hides /usr/share/emacs/29.0.50/
lisp/org/ox-ascii
/home/bidar/.emacs.d/elpa/org-9.5.4/org hides /usr/share/emacs/29.0.50/lisp/
org/org
/home/bidar/.emacs.d/elpa/org-9.5.4/org-version hides /usr/share/emacs/
29.0.50/lisp/org/org-version
/home/bidar/.emacs.d/elpa/org-9.5.4/org-timer hides /usr/share/emacs/29.0.50/
lisp/org/org-timer
/home/bidar/.emacs.d/elpa/org-9.5.4/org-tempo hides /usr/share/emacs/29.0.50/
lisp/org/org-tempo
/home/bidar/.emacs.d/elpa/org-9.5.4/org-table hides /usr/share/emacs/29.0.50/
lisp/org/org-table
/home/bidar/.emacs.d/elpa/org-9.5.4/org-src hides /usr/share/emacs/29.0.50/
lisp/org/org-src
/home/bidar/.emacs.d/elpa/org-9.5.4/org-refile hides /usr/share/emacs/29.0.50/
lisp/org/org-refile
/home/bidar/.emacs.d/elpa/org-9.5.4/org-protocol hides /usr/share/emacs/
29.0.50/lisp/org/org-protocol
/home/bidar/.emacs.d/elpa/org-9.5.4/org-plot hides /usr/share/emacs/29.0.50/
lisp/org/org-plot
/home/bidar/.emacs.d/elpa/org-9.5.4/org-pcomplete hides /usr/share/emacs/
29.0.50/lisp/org/org-pcomplete
/home/bidar/.emacs.d/elpa/org-9.5.4/org-num hides /usr/share/emacs/29.0.50/
lisp/org/org-num
/home/bidar/.emacs.d/elpa/org-9.5.4/org-mouse hides /usr/share/emacs/29.0.50/
lisp/org/org-mouse
/home/bidar/.emacs.d/elpa/org-9.5.4/org-mobile hides /usr/share/emacs/29.0.50/
lisp/org/org-mobile
/home/bidar/.emacs.d/elpa/org-9.5.4/org-macs hides /usr/share/emacs/29.0.50/
lisp/org/org-macs
/home/bidar/.emacs.d/elpa/org-9.5.4/org-macro hides /usr/share/emacs/29.0.50/
lisp/org/org-macro
/home/bidar/.emacs.d/elpa/org-9.5.4/org-loaddefs hides /usr/share/emacs/
29.0.50/lisp/org/org-loaddefs
/home/bidar/.emacs.d/elpa/org-9.5.4/org-list hides /usr/share/emacs/29.0.50/
lisp/org/org-list
/home/bidar/.emacs.d/elpa/org-9.5.4/org-lint hides /usr/share/emacs/29.0.50/
lisp/org/org-lint
/home/bidar/.emacs.d/elpa/org-9.5.4/org-keys hides /usr/share/emacs/29.0.50/
lisp/org/org-keys
/home/bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-install hides /usr/
share/emacs/29.0.50/lisp/org/org-install
/home/bidar/.emacs.d/elpa/org-9.5.4/org-inlinetask hides /usr/share/emacs/
29.0.50/lisp/org/org-inlinetask
/home/bidar/.emacs.d/elpa/org-9.5.4/org-indent hides /usr/share/emacs/29.0.50/
lisp/org/org-indent
/home/bidar/.emacs.d/elpa/org-9.5.4/org-id hides /usr/share/emacs/29.0.50/
lisp/org/org-id
/home/bidar/.emacs.d/elpa/org-9.5.4/org-habit hides /usr/share/emacs/29.0.50/
lisp/org/org-habit
/home/bidar/.emacs.d/elpa/org-9.5.4/org-goto hides /usr/share/emacs/29.0.50/
lisp/org/org-goto
/home/bidar/.emacs.d/elpa/org-9.5.4/org-footnote hides /usr/share/emacs/
29.0.50/lisp/org/org-footnote
/home/bidar/.emacs.d/elpa/org-9.5.4/org-feed hides /usr/share/emacs/29.0.50/
lisp/org/org-feed
/home/bidar/.emacs.d/elpa/org-9.5.4/org-faces hides /usr/share/emacs/29.0.50/
lisp/org/org-faces
/home/bidar/.emacs.d/elpa/org-9.5.4/org-entities hides /usr/share/emacs/
29.0.50/lisp/org/org-entities
/home/bidar/.emacs.d/elpa/org-9.5.4/org-element hides /usr/share/emacs/
29.0.50/lisp/org/org-element
/home/bidar/.emacs.d/elpa/org-9.5.4/org-duration hides /usr/share/emacs/
29.0.50/lisp/org/org-duration
/home/bidar/.emacs.d/elpa/org-9.5.4/org-datetree hides /usr/share/emacs/
29.0.50/lisp/org/org-datetree
/home/bidar/.emacs.d/elpa/org-9.5.4/org-ctags hides /usr/share/emacs/29.0.50/
lisp/org/org-ctags
/home/bidar/.emacs.d/elpa/org-9.5.4/org-crypt hides /usr/share/emacs/29.0.50/
lisp/org/org-crypt
/home/bidar/.emacs.d/elpa/org-9.5.4/org-compat hides /usr/share/emacs/29.0.50/
lisp/org/org-compat
/home/bidar/.emacs.d/elpa/org-9.5.4/org-colview hides /usr/share/emacs/
29.0.50/lisp/org/org-colview
/home/bidar/.emacs.d/elpa/org-9.5.4/org-clock hides /usr/share/emacs/29.0.50/
lisp/org/org-clock
/home/bidar/.emacs.d/elpa/org-9.5.4/org-capture hides /usr/share/emacs/
29.0.50/lisp/org/org-capture
/home/bidar/.emacs.d/elpa/org-9.5.4/org-attach hides /usr/share/emacs/29.0.50/
lisp/org/org-attach
/home/bidar/.emacs.d/elpa/org-9.5.4/org-attach-git hides /usr/share/emacs/
29.0.50/lisp/org/org-attach-git
/home/bidar/.emacs.d/elpa/org-9.5.4/org-archive hides /usr/share/emacs/
29.0.50/lisp/org/org-archive
/home/bidar/.emacs.d/elpa/org-9.5.4/org-agenda hides /usr/share/emacs/29.0.50/
lisp/org/org-agenda
/home/bidar/.emacs.d/elpa/org-9.5.4/ol hides /usr/share/emacs/29.0.50/lisp/
org/ol
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-w3m hides /usr/share/emacs/29.0.50/
lisp/org/ol-w3m
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-rmail hides /usr/share/emacs/29.0.50/
lisp/org/ol-rmail
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-mhe hides /usr/share/emacs/29.0.50/
lisp/org/ol-mhe
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-man hides /usr/share/emacs/29.0.50/
lisp/org/ol-man
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-irc hides /usr/share/emacs/29.0.50/
lisp/org/ol-irc
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-info hides /usr/share/emacs/29.0.50/
lisp/org/ol-info
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-gnus hides /usr/share/emacs/29.0.50/
lisp/org/ol-gnus
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-eww hides /usr/share/emacs/29.0.50/
lisp/org/ol-eww
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-eshell hides /usr/share/emacs/29.0.50/
lisp/org/ol-eshell
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-doi hides /usr/share/emacs/29.0.50/
lisp/org/ol-doi
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-docview hides /usr/share/emacs/29.0.50/
lisp/org/ol-docview
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-bibtex hides /usr/share/emacs/29.0.50/
lisp/org/ol-bibtex
/home/bidar/.emacs.d/elpa/org-9.5.4/ol-bbdb hides /usr/share/emacs/29.0.50/
lisp/org/ol-bbdb
/home/bidar/.emacs.d/elpa/org-9.5.4/oc hides /usr/share/emacs/29.0.50/lisp/
org/oc
/home/bidar/.emacs.d/elpa/org-9.5.4/oc-natbib hides /usr/share/emacs/29.0.50/
lisp/org/oc-natbib
/home/bidar/.emacs.d/elpa/org-9.5.4/oc-csl hides /usr/share/emacs/29.0.50/
lisp/org/oc-csl
/home/bidar/.emacs.d/elpa/org-9.5.4/oc-biblatex hides /usr/share/emacs/
29.0.50/lisp/org/oc-biblatex
/home/bidar/.emacs.d/elpa/org-9.5.4/oc-basic hides /usr/share/emacs/29.0.50/
lisp/org/oc-basic
/home/bidar/.emacs.d/elpa/org-9.5.4/ob hides /usr/share/emacs/29.0.50/lisp/
org/ob
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-tangle hides /usr/share/emacs/29.0.50/
lisp/org/ob-tangle
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-table hides /usr/share/emacs/29.0.50/
lisp/org/ob-table
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-sqlite hides /usr/share/emacs/29.0.50/
lisp/org/ob-sqlite
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-sql hides /usr/share/emacs/29.0.50/
lisp/org/ob-sql
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-shell hides /usr/share/emacs/29.0.50/
lisp/org/ob-shell
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-sed hides /usr/share/emacs/29.0.50/
lisp/org/ob-sed
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-screen hides /usr/share/emacs/29.0.50/
lisp/org/ob-screen
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-scheme hides /usr/share/emacs/29.0.50/
lisp/org/ob-scheme
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-sass hides /usr/share/emacs/29.0.50/
lisp/org/ob-sass
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-ruby hides /usr/share/emacs/29.0.50/
lisp/org/ob-ruby
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-ref hides /usr/share/emacs/29.0.50/
lisp/org/ob-ref
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-python hides /usr/share/emacs/29.0.50/
lisp/org/ob-python
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-processing hides /usr/share/emacs/
29.0.50/lisp/org/ob-processing
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-plantuml hides /usr/share/emacs/
29.0.50/lisp/org/ob-plantuml
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-perl hides /usr/share/emacs/29.0.50/
lisp/org/ob-perl
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-org hides /usr/share/emacs/29.0.50/
lisp/org/ob-org
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-octave hides /usr/share/emacs/29.0.50/
lisp/org/ob-octave
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-ocaml hides /usr/share/emacs/29.0.50/
lisp/org/ob-ocaml
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-maxima hides /usr/share/emacs/29.0.50/
lisp/org/ob-maxima
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-matlab hides /usr/share/emacs/29.0.50/
lisp/org/ob-matlab
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-makefile hides /usr/share/emacs/
29.0.50/lisp/org/ob-makefile
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-lua hides /usr/share/emacs/29.0.50/
lisp/org/ob-lua
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-lob hides /usr/share/emacs/29.0.50/
lisp/org/ob-lob
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-lisp hides /usr/share/emacs/29.0.50/
lisp/org/ob-lisp
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-lilypond hides /usr/share/emacs/
29.0.50/lisp/org/ob-lilypond
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-latex hides /usr/share/emacs/29.0.50/
lisp/org/ob-latex
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-julia hides /usr/share/emacs/29.0.50/
lisp/org/ob-julia
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-js hides /usr/share/emacs/29.0.50/lisp/
org/ob-js
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-java hides /usr/share/emacs/29.0.50/
lisp/org/ob-java
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-haskell hides /usr/share/emacs/29.0.50/
lisp/org/ob-haskell
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-groovy hides /usr/share/emacs/29.0.50/
lisp/org/ob-groovy
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-gnuplot hides /usr/share/emacs/29.0.50/
lisp/org/ob-gnuplot
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-fortran hides /usr/share/emacs/29.0.50/
lisp/org/ob-fortran
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-forth hides /usr/share/emacs/29.0.50/
lisp/org/ob-forth
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-exp hides /usr/share/emacs/29.0.50/
lisp/org/ob-exp
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-eval hides /usr/share/emacs/29.0.50/
lisp/org/ob-eval
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-eshell hides /usr/share/emacs/29.0.50/
lisp/org/ob-eshell
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-emacs-lisp hides /usr/share/emacs/
29.0.50/lisp/org/ob-emacs-lisp
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-dot hides /usr/share/emacs/29.0.50/
lisp/org/ob-dot
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-ditaa hides /usr/share/emacs/29.0.50/
lisp/org/ob-ditaa
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-css hides /usr/share/emacs/29.0.50/
lisp/org/ob-css
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-core hides /usr/share/emacs/29.0.50/
lisp/org/ob-core
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-comint hides /usr/share/emacs/29.0.50/
lisp/org/ob-comint
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-clojure hides /usr/share/emacs/29.0.50/
lisp/org/ob-clojure
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-calc hides /usr/share/emacs/29.0.50/
lisp/org/ob-calc
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-awk hides /usr/share/emacs/29.0.50/
lisp/org/ob-awk
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-R hides /usr/share/emacs/29.0.50/lisp/
org/ob-R
/home/bidar/.emacs.d/elpa/org-9.5.4/ob-C hides /usr/share/emacs/29.0.50/lisp/
org/ob-C

Features:
(shadow sort mail-extr emacsbug view epa-file guess-language
cursor-sensor winner tramp-archive tramp-gvfs helm-command helm-elisp
helm-eval edebug debug backtrace generic-x which-key beacon savehist
csharp-mode csharp-compilation cc-langs make-mode tramp-cache time-stamp
tramp-sh yaml-mode forge-list forge-commands forge-semi forge-bitbucket
buck forge-gogs gogs forge-gitea gtea forge-gitlab glab forge-github
ghub-graphql treepy gsexp ghub let-alist forge-notify forge-revnote
forge-pullreq forge-issue forge-topic yaml forge-post forge-repo forge
forge-core forge-db closql emacsql-sqlite emacsql emacsql-compiler
magit-bookmark magit-submodule magit-obsolete 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 magit-diff git-commit log-edit add-log magit-core
magit-autorevert magit-margin magit-transient magit-process magit-mode
transient markdown-mode edit-indirect mule-util whitespace
rainbow-delimiters rng-xsd xsd-regexp rng-cmpct rng-nxml rng-valid
nxml-mode nxml-outln nxml-rap sgml-mode org-eldoc cdlatex reftex
reftex-loaddefs reftex-vars texmathp ol-eww eww url-queue mm-url
ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect gnus-art mm-uu mml2015
mm-view mml-smime smime dig gnus-sum shr pixel-fill kinsoku url-file svg
dom gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail
mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range message
sendmail yank-media rfc822 mml mml-sec epa epg rfc6068 epg-config
mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader gnus-win
gnus nnheader gnus-util mail-utils range ol-docview doc-view jka-compr
ol-bibtex ol-bbdb ol-w3m ol-doi org-link-doi bat-mode smerge-mode diff
highlight-indent-guides dired-aux vc-hg vc-bzr vc-src vc-sccs vc-svn
vc-cvs vc-rcs log-view pcvs-util conf-mode vc bug-reference autorevert
company-oddmuse company-keywords company-etags company-gtags
company-dabbrev-code company-files company-clang company-cmake
company-semantic company-bbdb company-qml qmltypes-parser qml-mode js
imenu company-capf company-anaconda anaconda-mode pythonic f f-shortdoc
shortdoc python vc-git vc-dispatcher symbol-overlay ws-butler
editorconfig-core editorconfig-core-handle editorconfig-fnmatch
smart-mode-line-powerline-theme lui-track-bar lui-track company-emoji
company-emoji-list company-dabbrev helm-circe circe-notifications alert
log4e notifications dbus gntp circe-display-images circe-color-nicks
circe lui-irc-colors irc gnutls lcs lui-logging lui-format lui tracking
shorten flyspell ispell circe-compat helm-pass password-store
with-editor server auth-source-pass vterm term ehelp vterm-module
term/xterm xterm conf_edit-server edit-server conf_printing printing
ps-print ps-print-loaddefs lpr conf_clippboard conf_flyspell desktop
frameset so-long cursor-chg recentf tree-widget helm-bookmark helm-net
helm-adaptive helm-info helm-mode helm-misc helm-files image-dired xdg
image-mode dired dired-loaddefs exif filenotify helm-buffers helm-occur
helm-tags helm-locate helm-grep helm-regexp helm-utils helm-help
helm-types helm helm-global-bindings helm-easymenu helm-core
async-bytecomp helm-source helm-multi-match helm-lib async helm-config
smart-mode-line-respectful-theme smart-mode-line rich-minority
mode-icons emojify apropos tar-mode arc-mode archive-mode ht yasnippet
elec-pair vim-modeline diff-mode lua-mode magit-git magit-base
magit-section crm compat-27 compat-26 compat editorconfig projectile
lisp-mnt grep ibuf-ext ibuffer ibuffer-loaddefs ggtags etags fileloop
xref project ewoc nginx-mode flycheck-rtags cmake-ide s find-file
web-mode disp-table conf_pkgbuild pkgbuild-mode sh-script smie
executable 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 puny xml ox-extra org-tree-slide org-timer
org-clock outshine outshine-org-cmds outorg ox-koma-letter 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 org-agenda
org-refile ox-html table ox-ascii ox-publish ox org-element avl-tree
generator ob-latex ob-dot ob-plantuml 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 ol org-keys oc
org-compat org-macs org-loaddefs cal-menu calendar cal-loaddefs htmlize
cl conf-perl company-rtags company-template rtags popup repeat thingatpt
compile tramp tramp-loaddefs trampver tramp-integration cus-edit
cus-load wid-edit files-x tramp-compat shell pcomplete comint parse-time
iso8601 time-date ls-lisp format-spec asm-mode bookmark
text-property-search cperl-mode facemenu conf_qt semantic/bovine/c
hideif semantic/bovine/c-by semantic/lex-spp semantic/idle
semantic/bovine/gcc semantic/dep semantic/bovine semantic/analyze/refs
semantic/db-find semantic/db-ref semantic/analyze semantic/sort
semantic/scope semantic/analyze/fcn semantic/db eieio-base semantic/ctxt
semantic/format ezimage semantic/tag-ls semantic/find
semantic/util-modes semantic/util semantic pp semantic/tag semantic/lex
semantic/fw mode-local cedet qt-pro derived edmacro kmacro cc-mode
cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars
cc-defs conf_flycheck flycheck-color-mode-line face-remap flycheck
ansi-color find-func dash use-package-bind-key bind-key easy-mmode
company pcase saveplace ir-black-theme gcmh use-package-ensure
use-package-core conf_package finder-inf beacon-autoloads
cdlatex-autoloads tex-site cmake-mode-autoloads anaconda-mode-autoloads
company-emojify-autoloads csharp-mode-autoloads ein-autoloads
forge-autoloads gcmh-autoloads ghub-autoloads company-autoloads
flycheck-autoloads helm-autoloads helm-core-autoloads async-autoloads
lsp-java-autoloads dap-mode-autoloads lsp-docker-autoloads
lsp-ui-autoloads lsp-mode-autoloads magit-libgit-autoloads
magit-autoloads git-commit-autoloads libgit-autoloads
magit-section-autoloads powerline comp comp-cstr warnings icons rx
cl-extra help-mode advice powerline-separators ring color
powerline-themes all-the-icons-autoloads markdown-mode-autoloads
org-contrib-autoloads pdf-tools-autoloads projectile-autoloads
pythonic-autoloads f-autoloads request-autoloads transient-autoloads
treemacs-autoloads dash-autoloads with-editor-autoloads info
compat-autoloads xr-autoloads yaml-autoloads package browse-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x
map byte-opt gv bytecomp byte-compile cconv url-vars cl-loaddefs cl-lib
rmc iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win term/common-win
pgtk-dnd 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
nadvice seq simple cl-generic indonesian philippine 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 abbrev obarray oclosure
cl-preloaded button loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
gtk pgtk lcms2 multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 1519175 1505133)
 (symbols 48 74463 58)
 (strings 32 392180 270445)
 (string-bytes 1 11781428)
 (vectors 16 183178)
 (vector-slots 8 5401424 2075944)
 (floats 8 1181 4688)
 (intervals 56 35573 13613)
 (buffers 992 455))

bug#56967: 29.0.50; Frequent crashes under Wayland

[Eli Zaretskii]

> Date: Thu, 04 Aug 2022 10:36:50 +0300
> From:  Bjoern Bidar via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> To trigger the bug there needs to be some usage so I'm not sure how to
> trigger the bug with ~emacs -Q~.
> However Emacs just stops usually, sometimes emacs freezes for a few sec 
> before.
> I start emacs as a systemd --user service, systemd reports that emacs
> stops like this:
> emacs.service: Main process exited, code=exited, status=1/FAILURE
> 
> No other output or crashdump is there.
> 
> It happens after a time, sometimes it fails after hours sometimes it fails 
> after 10 minues.

Please do provide some data we can work with: either a recipe to
reproduce the crash, or the backtrace from a debugger when the crash
happens (you can obtain the latter if you run Emacs under a debugger
to begin with).

Thanks.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Eli Zaretskii]

[Please use Reply All to reply, to keep the bug tracker on the CC.]

> From: Bjoern Bidar <bjorn.bidar@thaodan.de>
> Date: Thu, 04 Aug 2022 11:05:00 +0300
> 
> The issue is that Emacs doesn't crash, it just exists with 1.
> 
> The recipe to reproduce the bug is to just use emacs and wait till it crashes.
> 
> I start emacs like this:
> # /home/user/.config/systemd/user/emacs.service
> 
> [Unit]
> Description=Emacs: the extensible, self-documenting text editor
> Wants=graphical.target
> Wants=environment.target
> 
> [Service]
> Type=forking
> ExecStart=/usr/bin/emacs --daemon
> ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)"
> Environment=SSH_AUTH_SOCK=%t/keyring/ssh
> Environment=GDK_DPI_SCALE=2
> Environment=GDK_SCALE=2
> Restart=always
> TimeoutStartSec=0
> [Install]
> WantedBy=default.target
> 
> # /home/user/.config/systemd/user/emacs.service.d/override.conf
> [Service]
> TimeoutStopSec=600

Then please run Emacs under a debugger, or attach a debugger to it
after you start it, and place a breakpoint in the function
Fkill_emacs.  When that breakpoint breaks, produce a backtrace (with
the "thread apply all bt" command in GDB) and post that backtrace
here.

> I'm not sure if it helps but the most crashes I experienced when using irc 
> through circe.

It depends on what we will see in the backtrace.

Thanks.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> [Please use Reply All to reply, to keep the bug tracker on the CC.]

Indeed.  When you reply the wrong way, other people with relevant things
to say cannot respond.

>> The issue is that Emacs doesn't crash, it just exists with 1.
>> 
>> The recipe to reproduce the bug is to just use emacs and wait till it crashes.
>> 
>> I start emacs like this:
>> # /home/user/.config/systemd/user/emacs.service
>> 
>> [Unit]
>> Description=Emacs: the extensible, self-documenting text editor
>> Wants=graphical.target
>> Wants=environment.target
>> 
>> [Service]
>> Type=forking
>> ExecStart=/usr/bin/emacs --daemon
>> ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)"
>> Environment=SSH_AUTH_SOCK=%t/keyring/ssh
>> Environment=GDK_DPI_SCALE=2
>> Environment=GDK_SCALE=2
>> Restart=always
>> TimeoutStartSec=0
>> [Install]
>> WantedBy=default.target
>> 
>> # /home/user/.config/systemd/user/emacs.service.d/override.conf
>> [Service]
>> TimeoutStopSec=600

> Then please run Emacs under a debugger, or attach a debugger to it
> after you start it, and place a breakpoint in the function
> Fkill_emacs.  When that breakpoint breaks, produce a backtrace (with
> the "thread apply all bt" command in GDB) and post that backtrace
> here.

Please also place a breakpoint on _exit -- GDK always calls that with
the exit code 1 that when a display connection is abruptly lost, in
which case Fkill_emacs has no chance to run.

Thanks in advance.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Bjoern Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Eli Zaretskii <eliz@gnu.org> writes:

> > Then please run Emacs under a debugger, or attach a debugger to it
> > after you start it, and place a breakpoint in the function
> > Fkill_emacs.  When that breakpoint breaks, produce a backtrace (with
> > the "thread apply all bt" command in GDB) and post that backtrace
> > here.
> 
> Please also place a breakpoint on _exit -- GDK always calls that with
> the exit code 1 that when a display connection is abruptly lost, in
> which case Fkill_emacs has no chance to run.
> 
> Thanks in advance.

Started emacs via systemd as and set both break points as asked.

There you go:


Thread 1 "emacs" hit Breakpoint 2, __GI__exit (status=status@entry=1) at ../
sysdeps/unix/sysv/linux/_exit.c:27
27      {
(gdb) bt
#0  __GI__exit (status=status@entry=1) at ../sysdeps/unix/sysv/linux/_exit.c:
27
#1  0x00007fdac9c825ae in gdk_event_source_check 
(base=base@entry=0x5626b0eb7770) at ../gtk/gdk/wayland/gdkeventsource.c:97
#2  0x00007fdac962411f in g_main_context_check (context=0x5626b71d9be0, 
max_priority=2147483647, fds=<optimized out>, n_fds=<optimized out>) at ../
glib/glib/gmain.c:4035
#3  0x00007fdac9679e5e in g_main_context_iterate.constprop.0 
(context=context@entry=0x5626b71d9be0, block=block@entry=0, 
dispatch=dispatch@entry=0, self=<optimized out>) at ../glib/glib/gmain.c:4208
#4  0x00007fdac962132d in g_main_context_pending (context=0x5626b71d9be0) at 
../glib/glib/gmain.c:4241
#5  0x00005626ab4f3bd2 in pgtk_read_socket.lto_priv ()
#6  0x00005626ab3a3731 in gobble_input ()
#7  0x00005626ab3a3ba5 in unblock_input ()
#8  0x00005626ab4c7f23 in ftcrfont_text_extents.lto_priv ()
#9  0x00005626ab30e4a5 in gui_produce_glyphs ()
#10 0x00005626ab2fcb90 in display_line.lto_priv ()
#11 0x00005626ab2ef021 in try_window ()
#12 0x00005626ab2f6641 in redisplay_window.lto_priv ()
#13 0x00005626ab2e7a1e in redisplay_window_1 ()
#14 0x00005626ab427ecc in internal_condition_case_1 ()
#15 0x00005626ab2ec09a in redisplay_internal.lto_priv ()
#16 0x00005626ab51c025 in redisplay_preserve_echo_area.constprop ()
#17 0x00005626ab49e8d6 in wait_reading_process_output ()
#18 0x00005626ab2b6419 in sit_for ()
#19 0x00005626ab3a0f02 in read_char ()
#20 0x00005626ab3a83f4 in read_key_sequence.lto_priv ()
#21 0x00005626ab39bba8 in command_loop_1.lto_priv ()
#22 0x00005626ab427e37 in internal_condition_case ()
#23 0x00005626ab3939ce in command_loop_2 ()
#24 0x00005626ab427d7a in internal_catch ()
#25 0x00005626ab396cd9 in command_loop.lto_priv ()
#26 0x00005626ab5298ab in recursive_edit_1.isra ()
#27 0x00005626ab397090 in Frecursive_edit ()
#28 0x00005626ab2aac2f in main ()
(gdb) 

bug#56967: 29.0.50; Frequent crashes under Wayland

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Bjoern Bidar <bjorn.bidar@thaodan.de> writes:

>> Eli Zaretskii <eliz@gnu.org> writes:
>
>> > Then please run Emacs under a debugger, or attach a debugger to it
>> > after you start it, and place a breakpoint in the function
>> > Fkill_emacs.  When that breakpoint breaks, produce a backtrace (with
>> > the "thread apply all bt" command in GDB) and post that backtrace
>> > here.
>> 
>> Please also place a breakpoint on _exit -- GDK always calls that with
>> the exit code 1 that when a display connection is abruptly lost, in
>> which case Fkill_emacs has no chance to run.
>> 
>> Thanks in advance.
>
> Started emacs via systemd as and set both break points as asked.
>
> There you go:
>
>
> Thread 1 "emacs" hit Breakpoint 2, __GI__exit (status=status@entry=1) at ../
> sysdeps/unix/sysv/linux/_exit.c:27
> 27      {
> (gdb) bt
> #0  __GI__exit (status=status@entry=1) at ../sysdeps/unix/sysv/linux/_exit.c:
> 27
> #1  0x00007fdac9c825ae in gdk_event_source_check 
> (base=base@entry=0x5626b0eb7770) at ../gtk/gdk/wayland/gdkeventsource.c:97
> #2  0x00007fdac962411f in g_main_context_check (context=0x5626b71d9be0, 
> max_priority=2147483647, fds=<optimized out>, n_fds=<optimized out>) at ../
> glib/glib/gmain.c:4035
> #3  0x00007fdac9679e5e in g_main_context_iterate.constprop.0 
> (context=context@entry=0x5626b71d9be0, block=block@entry=0, 
> dispatch=dispatch@entry=0, self=<optimized out>) at ../glib/glib/gmain.c:4208
> #4  0x00007fdac962132d in g_main_context_pending (context=0x5626b71d9be0) at 
> ../glib/glib/gmain.c:4241
> #5  0x00005626ab4f3bd2 in pgtk_read_socket.lto_priv ()

That's what I thought might be happening.  Emacs calls
g_main_context_pending to read events from GDK, which notices that the
display connection has been abruptly terminated, and calls _exit to
abort.

Unfortunately, there's no way for us to fix this inside Emacs, so I
guess you should look into why Wayland display connections are so
unstable on your system.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  56967@debbugs.gnu.org
> Date: Fri, 05 Aug 2022 08:50:39 +0800
> 
> That's what I thought might be happening.  Emacs calls
> g_main_context_pending to read events from GDK, which notices that the
> display connection has been abruptly terminated, and calls _exit to
> abort.
> 
> Unfortunately, there's no way for us to fix this inside Emacs, so I
> guess you should look into why Wayland display connections are so
> unstable on your system.

Does _exit in glibc provide any hooks that we could use?  Emacs cannot
be the first application that doesn't want misbehaving libraries to
forcibly exit it.

Or maybe GTK has some knob to let it call us before it calls _exit?

bug#56967: 29.0.50; Frequent crashes under Wayland

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Does _exit in glibc provide any hooks that we could use?

Not that I know of.

> Emacs cannot be the first application that doesn't want misbehaving
> libraries to forcibly exit it.

It literally is, in the case of users of GDK.

> Or maybe GTK has some knob to let it call us before it calls _exit?

Nope, GTK simply does this:

  if (wl_display_flush (display->wl_display) < 0)
    {
      g_message ("Error flushing display: %s", g_strerror (errno));
      _exit (1);
    }

if (for example) wl_display_flush, a low-level Wayland interface, fails
from an IO error.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: bjorn.bidar@thaodan.de,  56967@debbugs.gnu.org
> Date: Fri, 05 Aug 2022 14:28:21 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Does _exit in glibc provide any hooks that we could use?
> 
> Not that I know of.

How about asking the glibc developers to provide one, citing this very
use case as the real-life problem to solve?  Specifically, what I'd
like to do in that hook is to shut down Emacs in an orderly manner, so
that the user won't lose all his/her edits.

> > Or maybe GTK has some knob to let it call us before it calls _exit?
> 
> Nope, GTK simply does this:
> 
>   if (wl_display_flush (display->wl_display) < 0)
>     {
>       g_message ("Error flushing display: %s", g_strerror (errno));
>       _exit (1);
>     }
> 
> if (for example) wl_display_flush, a low-level Wayland interface, fails
> from an IO error.

Amazing.  Where did those people learn to develop friendly, extensible
libraries? in what tyrannical culture?

bug#56967: 29.0.50; Frequent crashes under Wayland

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> How about asking the glibc developers to provide one, citing this very
> use case as the real-life problem to solve?  Specifically, what I'd
> like to do in that hook is to shut down Emacs in an orderly manner, so
> that the user won't lose all his/her edits.

By running the code inside `shut_down_emacs'? I will indeed ask for such
a hook.

>> > Or maybe GTK has some knob to let it call us before it calls _exit?
>> 
>> Nope, GTK simply does this:
>> 
>>   if (wl_display_flush (display->wl_display) < 0)
>>     {
>>       g_message ("Error flushing display: %s", g_strerror (errno));
>>       _exit (1);
>>     }
>> 
>> if (for example) wl_display_flush, a low-level Wayland interface, fails
>> from an IO error.
>
> Amazing.  Where did those people learn to develop friendly, extensible
> libraries? in what tyrannical culture?

I'd say their culture has changed in the past decade and is now pretty
close to Apple's.  Unfortunately, Wayland is gaining popularity (as
evidenced by the amount of our users who report related bugs), and GTK
is the only toolkit that provides useful support for it.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: bjorn.bidar@thaodan.de,  56967@debbugs.gnu.org
> Date: Fri, 05 Aug 2022 14:53:19 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How about asking the glibc developers to provide one, citing this very
> > use case as the real-life problem to solve?  Specifically, what I'd
> > like to do in that hook is to shut down Emacs in an orderly manner, so
> > that the user won't lose all his/her edits.
> 
> By running the code inside `shut_down_emacs'?

Yes.

> I will indeed ask for such a hook.

Thanks.

> > Amazing.  Where did those people learn to develop friendly, extensible
> > libraries? in what tyrannical culture?
> 
> I'd say their culture has changed in the past decade and is now pretty
> close to Apple's.  Unfortunately, Wayland is gaining popularity (as
> evidenced by the amount of our users who report related bugs), and GTK
> is the only toolkit that provides useful support for it.

Maybe we should keep complaining there until someone hears us.
Calling _exit after printing an error message is not a reasonable
thing to do in a general-purpose library.  Exiting is something an
application should do.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Bjoern Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Am Freitag, 5. August 2022, 10:46:03 EEST schrieb Eli Zaretskii:
> > From: Po Lu <luangruo@yahoo.com>
> > Cc: bjorn.bidar@thaodan.de,  56967@debbugs.gnu.org
> > Date: Fri, 05 Aug 2022 14:53:19 +0800
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > > How about asking the glibc developers to provide one, citing this very
> > > use case as the real-life problem to solve?  Specifically, what I'd
> > > like to do in that hook is to shut down Emacs in an orderly manner, so
> > > that the user won't lose all his/her edits.
> > 
> > By running the code inside `shut_down_emacs'?
> 
> Yes.
> 
> > I will indeed ask for such a hook.
> 
> Thanks.
> 
> > > Amazing.  Where did those people learn to develop friendly, extensible
> > > libraries? in what tyrannical culture?
> > 
> > I'd say their culture has changed in the past decade and is now pretty
> > close to Apple's.  Unfortunately, Wayland is gaining popularity (as
> > evidenced by the amount of our users who report related bugs), and GTK
> > is the only toolkit that provides useful support for it.
> 
> Maybe we should keep complaining there until someone hears us.
> Calling _exit after printing an error message is not a reasonable
> thing to do in a general-purpose library.  Exiting is something an
> application should do.
I agree.
Is there an existing bug for this? This reminds me of a similar bug in the X11 
session that still isn't fixed.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Bjoern Bidar <bjorn.bidar@thaodan.de> writes:


> I agree.  Is there an existing bug for this? This reminds me of a
> similar bug in the X11 session that still isn't fixed.

There are several, the bug in the X11 backend applies (in a general
sense) to this as well.

The difference is there used to be a semi-working workaround provided by
Xlib, involving longjmp, whose developers thankfully do not share the
GTK approach to error handling.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Bjoern Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Am Freitag, 5. August 2022, 09:28:21 EEST schrieb Po Lu:
> Eli Zaretskii <eliz@gnu.org> writes:
> > Does _exit in glibc provide any hooks that we could use?
> 
> Not that I know of.
> 
> > Emacs cannot be the first application that doesn't want misbehaving
> > libraries to forcibly exit it.
> 
> It literally is, in the case of users of GDK.
> 
> > Or maybe GTK has some knob to let it call us before it calls _exit?
> 
> Nope, GTK simply does this:
> 
>   if (wl_display_flush (display->wl_display) < 0)
>     {
>       g_message ("Error flushing display: %s", g_strerror (errno));
>       _exit (1);
>     }
> 
> if (for example) wl_display_flush, a low-level Wayland interface, fails
> from an IO error.
How should any app clean up after it selfs when GTK just closes it?

bug#56967: 29.0.50; Frequent crashes under Wayland

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Bjoern Bidar <bjorn.bidar@thaodan.de> writes:

> How should any app clean up after it selfs when GTK just closes it?

Programs cannot at present.  I've asked the glibc developers for an
appropriate hook.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Gregory Heytings]

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


>
> Does _exit in glibc provide any hooks that we could use?  Emacs cannot 
> be the first application that doesn't want misbehaving libraries to 
> forcibly exit it.
>

It's possible (albeit tricky) to escape an _exit() call by using 
LD_PRELOAD, see attached example.  Whether this is usable for Emacs, I 
don't know.

[-- Attachment #2: escape-exit.tgz --]
[-- Type: application/x-gtar-compressed, Size: 743 bytes --]

bug#56967: 29.0.50; Frequent crashes under Wayland

[Eli Zaretskii]

> Date: Fri, 05 Aug 2022 11:40:36 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Po Lu <luangruo@yahoo.com>, 56967@debbugs.gnu.org, bjorn.bidar@thaodan.de
> 
> > Does _exit in glibc provide any hooks that we could use?  Emacs cannot 
> > be the first application that doesn't want misbehaving libraries to 
> > forcibly exit it.
> 
> It's possible (albeit tricky) to escape an _exit() call by using 
> LD_PRELOAD, see attached example.  Whether this is usable for Emacs, I 
> don't know.

Interesting.  I'll defer to Linux experts to tell whether this is
something we could/should use.

Thanks.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[*Please* use "Reply All" to reply, otherwise your response will not be
recorded on the bug tracker]

Bjoern Bidar <bjorn.bidar@thaodan.de> writes:

> That's the thing it doesn't look like the connection is unstabl alos nothing 
> else but Emacs has this issue.

Did you leave anything else up for long enough? Try keeping gtk3-demo up
for a similar amount of time.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Bjoern Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Am Freitag, 5. August 2022, 09:29:47 EEST schrieb Po Lu:
> [*Please* use "Reply All" to reply, otherwise your response will not be
> recorded on the bug tracker]
> 
> Bjoern Bidar <bjorn.bidar@thaodan.de> writes:
> > That's the thing it doesn't look like the connection is unstabl alos
> > nothing else but Emacs has this issue.
> 
> Did you leave anything else up for long enough? Try keeping gtk3-demo up
> for a similar amount of time.

I did I had my hole session running, nothing else had that issue.
I kept the GTK-Demo running nothing happened it ran just fine.

After a few hours Emacs exited with the same behaviour as explained in the 
bug.

I on the #gtk channel on what do and I got from ebassi that it is ok to just 
call _exit.
He says it might be the client behaving wrong:
<ebassi> Thaodan: It could happen because the client made an invalid request—
Wayland mandates that the display server closes the connection in that case

I don't really understand why calling _exit is an acceptable solution anyone 
that has to safe some state to the disk is lost.

I attach the whole conversation to not take anything out of context here:
<Thaodan> Hello why does GTK call _exit when a display connection is lost in 
wayland, how can the app react to  loosing the display connection?
<Thaodan> I noticed that Emacs sometimes looses the display connection under 
Wayland (not XWayland).
<ebassi> You don't
<ebassi> If a client loses the connection to a running compositor then it's 
generally a bug in the client
<ebassi> If you lose the connection to the display server all hope is 
generally lost
<Thaodan> ebassi: An app may run longer or before the compositor starts even 
if not it's not nice as an application to just quit and not even let the 
application clean up after it self.
<ebassi> In theory, under Wayland, it might be possible to clean all data 
attached to the display, but it's unlikely this will ever work without 
applications dealing with it
<ebassi> And if you lose the socket then you'
<ebassi> you'll have to find the new one and reconnect
<ebassi> Thaodan: Only emacs does that
<ebassi> Pretty much literally
<Thaodan> "that"?
<ebassi> "app may run longer or before the compositor starts"
<ebassi> Because emacs is really a 1980s teletype app
<Thaodan> What does that change? calling _exit is not a solution.
<Thaodan> Lets assume the fault for this happening is emacs, what could cause 
this?
<ebassi> Calling exit is perfectly acceptable: the display connection is 
severed, and that can happen for multiple reasons, including the display 
server going away
<ebassi> There's no "the display server is still running, but it closed the 
socket" mechanism for the toolkit to use
<ebassi> The socket got closed
<ebassi> The toolkit terminates
<ebassi> Thaodan: It could happen because the client made an invalid request—
Wayland mandates that the display server closes the connection in that case
<ebassi> Or the display server decided to kill the client because it was 
unresponsive
<Thaodan> Why should the toolkit/lib call exit isn't there any better 
mechanism to doing such a thing in glib or gtk for that matter? 
<Thaodan> It would be better to not need any hacks to prevent gtk from killing 
apps.
<ebassi> Thaodan: There is no such mechanism
<Thaodan> ebassi: OK so what's the idea behind using _exit as a mechanism, 
doesn't that break any other app that has state so safe too? like for example 
an office application that wants to safe it's data before going down.
<ebassi> I already told you
<ebassi> If the display connection is closed by the server, then there's no 
safe way to store the data

bug#56967: 29.0.50; Frequent crashes under Wayland

[Eli Zaretskii]

> Cc: 56967@debbugs.gnu.org
> Date: Sun, 07 Aug 2022 17:51:25 +0300
> From:  Bjoern Bidar via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> I on the #gtk channel on what do and I got from ebassi that it is ok to just 
> call _exit.
> He says it might be the client behaving wrong:
> <ebassi> Thaodan: It could happen because the client made an invalid request—
> Wayland mandates that the display server closes the connection in that case
> 
> I don't really understand why calling _exit is an acceptable solution anyone 
> that has to safe some state to the disk is lost.
> 
> I attach the whole conversation to not take anything out of context here:

Those guys evidently think that an application without display cannot
do anything.  They forget that even if display connection is lost, and
even if this is due to some fault of the application, that application
could still shut down gracefully instead of losing all of the user's
work, if only GTK wouldn't call _exit "because it's acceptable", or
"because emacs is a 1980s teletype app", or because whatever other
ridiculous justifications these guys come up for such misconduct.

> <ebassi> I already told you
> <ebassi> If the display connection is closed by the server, then there's no 
> safe way to store the data

Really?  Since when does saving data to disk require a display
connection??

bug#56967: 29.0.50; Frequent crashes under Wayland

[Bjoern Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Am Sonntag, 7. August 2022, 18:07:29 EEST schrieb Eli Zaretskii:
> > Cc: 56967@debbugs.gnu.org
> > Date: Sun, 07 Aug 2022 17:51:25 +0300
> > From:  Bjoern Bidar via "Bug reports for GNU Emacs,
> > 
> >  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> > 
> > I on the #gtk channel on what do and I got from ebassi that it is ok to
> > just call _exit.
> > He says it might be the client behaving wrong:
> > <ebassi> Thaodan: It could happen because the client made an invalid
> > request— Wayland mandates that the display server closes the connection
> > in that case
> > 
> > I don't really understand why calling _exit is an acceptable solution
> > anyone that has to safe some state to the disk is lost.
> 
> > I attach the whole conversation to not take anything out of context here:
> Those guys evidently think that an application without display cannot
> do anything.  They forget that even if display connection is lost, and
> even if this is due to some fault of the application, that application
> could still shut down gracefully instead of losing all of the user's
> work, if only GTK wouldn't call _exit "because it's acceptable", or
> "because emacs is a 1980s teletype app", or because whatever other
> ridiculous justifications these guys come up for such misconduct.

I don't know what to say, I'm befuddled too.
The audacity to act such a way as a library.

> > <ebassi> I already told you
> > <ebassi> If the display connection is closed by the server, then there's
> > no
> > safe way to store the data
> 
> Really?  Since when does saving data to disk require a display
> connection??

I don't know either, this is what came after:

<ebassi> Because the toolkit has no idea what's left of the system's integrity
<two[m]> how could it start before the compositor?
<Thaodan> the display connection lost doesn't mean the whole system is broken 
but just the compositor. But I assume that the toolkit takes precedence over 
the app it self.
<ebassi> Thaodan: You literally **cannot** know that
<Thaodan> two[m]: background services such as systemd --user services
<two[m]> wouldn't it fail because no $WAYLAND_DISPLAY?
*** First activity: MichaelNazzarenoTrimarchi[m] joined 53 minutes 11 seconds 
ago.
<MichaelNazzarenoTrimarchi[m]> Well the app can really do anything before 
starting the graphic subsystem. It can even wait that Wayland service is 
started before do any specific toolkit initialization 
<Thaodan> MichaelNazzarenoTrimarchi[m]: Exactly, apps such as editors might 
reload their last session which can take quite some time 
<Thaodan> There it makes sense to start as early as possible.
<Thaodan> How can I find out if GTK did an invalid request to the compositor?
<MichaelNazzarenoTrimarchi[m]> That is simple 
<MichaelNazzarenoTrimarchi[m]> You can activate Wayland tracing of message
<MichaelNazzarenoTrimarchi[m]> You can see then message sent to compositor
<MichaelNazzarenoTrimarchi[m]> It's rather difficult that is an application 
bug but could be a client side Wayland part bug

bug#56967: 29.0.50; Frequent crashes under Wayland

[Eli Zaretskii]

> From: Bjoern Bidar <bjorn.bidar@thaodan.de>
> Cc: luangruo@yahoo.com, 56967@debbugs.gnu.org
> Date: Sun, 07 Aug 2022 18:14:50 +0300
> 
> > > <ebassi> I already told you
> > > <ebassi> If the display connection is closed by the server, then there's
> > > no
> > > safe way to store the data
> > 
> > Really?  Since when does saving data to disk require a display
> > connection??
> 
> I don't know either, this is what came after:
> 
> <ebassi> Because the toolkit has no idea what's left of the system's integrity
> <two[m]> how could it start before the compositor?
> <Thaodan> the display connection lost doesn't mean the whole system is broken 
> but just the compositor. But I assume that the toolkit takes precedence over 
> the app it self.
> <ebassi> Thaodan: You literally **cannot** know that

A tail wagging the dog, really...

bug#56967: 29.0.50; Frequent crashes under Wayland

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Bjoern Bidar <bjorn.bidar@thaodan.de> writes:

> <MichaelNazzarenoTrimarchi[m]> That is simple 
> <MichaelNazzarenoTrimarchi[m]> You can activate Wayland tracing of message
> <MichaelNazzarenoTrimarchi[m]> You can see then message sent to compositor
> <MichaelNazzarenoTrimarchi[m]> It's rather difficult that is an application 
> bug but could be a client side Wayland part bug

That's a good idea, but I don't remember how to do that.  Perhaps you
should ask there.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Bjoern Bidar <bjorn.bidar@thaodan.de> writes:

> I did I had my hole session running, nothing else had that issue.
> I kept the GTK-Demo running nothing happened it ran just fine.

Thanks.

> After a few hours Emacs exited with the same behaviour as explained in the 
> bug.

Do you see the same if you run Emacs as something other a daemon?

> I on the #gtk channel on what do and I got from ebassi that it is ok to just 
> call _exit.
> He says it might be the client behaving wrong:
> <ebassi> Thaodan: It could happen because the client made an invalid request—
> Wayland mandates that the display server closes the connection in that case

We don't make raw Wayland requests anywhere, so it must be a bug in GTK.

> <ebassi> And if you lose the socket then you'
> <ebassi> you'll have to find the new one and reconnect
> <ebassi> Thaodan: Only emacs does that
> <ebassi> Pretty much literally
> <Thaodan> "that"?
> <ebassi> "app may run longer or before the compositor starts"
> <ebassi> Because emacs is really a 1980s teletype app
> <Thaodan> What does that change? calling _exit is not a solution.
> <Thaodan> Lets assume the fault for this happening is emacs, what could cause 
> this?

Outdated information.  The PGTK port of Emacs doesn't do anything close
to that, because GTK doesn't let us.

> <ebassi> Calling exit is perfectly acceptable: the display connection is 
> severed, and that can happen for multiple reasons, including the display 
> server going away
> <ebassi> There's no "the display server is still running, but it closed the 
> socket" mechanism for the toolkit to use

So why not use exit, which lets the atexit handlers run?

> <ebassi> The socket got closed
> <ebassi> The toolkit terminates
> <ebassi> Thaodan: It could happen because the client made an invalid request—
> Wayland mandates that the display server closes the connection in that case
> <ebassi> Or the display server decided to kill the client because it was 
> unresponsive
> <Thaodan> Why should the toolkit/lib call exit isn't there any better 
> mechanism to doing such a thing in glib or gtk for that matter? 
> <Thaodan> It would be better to not need any hacks to prevent gtk from killing 
> apps.
> <ebassi> Thaodan: There is no such mechanism
> <Thaodan> ebassi: OK so what's the idea behind using _exit as a mechanism, 
> doesn't that break any other app that has state so safe too? like for example 
> an office application that wants to safe it's data before going down.
> <ebassi> I already told you
> <ebassi> If the display connection is closed by the server, then there's no 
> safe way to store the data

Store the data that is in Emacs core??  How did these people learn to
write software?

bug#56967: 29.0.50; Frequent crashes under Wayland

[Bjoern Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Am Montag, 8. August 2022, 05:40:30 EEST schrieb Po Lu:
> Bjoern Bidar <bjorn.bidar@thaodan.de> writes:
> > I did I had my hole session running, nothing else had that issue.
> > I kept the GTK-Demo running nothing happened it ran just fine.
> 
> Thanks.
> 
> > After a few hours Emacs exited with the same behaviour as explained in the
> > bug.
> 
> Do you see the same if you run Emacs as something other a daemon?

I didn't but I can try. Maybe something in the environment variables is 
different.

> > I on the #gtk channel on what do and I got from ebassi that it is ok to
> > just call _exit.
> > He says it might be the client behaving wrong:
> > <ebassi> Thaodan: It could happen because the client made an invalid
> > request— Wayland mandates that the display server closes the connection
> > in that case
> We don't make raw Wayland requests anywhere, so it must be a bug in GTK.
> 
> > <ebassi> And if you lose the socket then you'
> > <ebassi> you'll have to find the new one and reconnect
> > <ebassi> Thaodan: Only emacs does that
> > <ebassi> Pretty much literally
> > <Thaodan> "that"?
> > <ebassi> "app may run longer or before the compositor starts"
> > <ebassi> Because emacs is really a 1980s teletype app
> > <Thaodan> What does that change? calling _exit is not a solution.
> > <Thaodan> Lets assume the fault for this happening is emacs, what could
> > cause this?
> 
> Outdated information.  The PGTK port of Emacs doesn't do anything close
> to that, because GTK doesn't let us.

I guess that is his bias or prejudice about Emacs. 

> > <ebassi> Calling exit is perfectly acceptable: the display connection is
> > severed, and that can happen for multiple reasons, including the display
> > server going away
> > <ebassi> There's no "the display server is still running, but it closed
> > the
> > socket" mechanism for the toolkit to use
> 
> So why not use exit, which lets the atexit handlers run?
> 
> > <ebassi> The socket got closed
> > <ebassi> The toolkit terminates
> > <ebassi> Thaodan: It could happen because the client made an invalid
> > request— Wayland mandates that the display server closes the connection
> > in that case <ebassi> Or the display server decided to kill the client
> > because it was unresponsive
> > <Thaodan> Why should the toolkit/lib call exit isn't there any better
> > mechanism to doing such a thing in glib or gtk for that matter?
> > <Thaodan> It would be better to not need any hacks to prevent gtk from
> > killing apps.
> > <ebassi> Thaodan: There is no such mechanism
> > <Thaodan> ebassi: OK so what's the idea behind using _exit as a mechanism,
> > doesn't that break any other app that has state so safe too? like for
> > example an office application that wants to safe it's data before going
> > down. <ebassi> I already told you
> > <ebassi> If the display connection is closed by the server, then there's
> > no
> > safe way to store the data
> 
> Store the data that is in Emacs core??  How did these people learn to
> write software?

I don't know but with such ignorance I don't see why anyone wants to use GTK.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Bjoern Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Am Montag, 8. August 2022, 05:40:30 EEST schrieb Po Lu:
> Bjoern Bidar <bjorn.bidar@thaodan.de> writes:
> > I did I had my hole session running, nothing else had that issue.
> > I kept the GTK-Demo running nothing happened it ran just fine.
> 
> Thanks.
> 
> > After a few hours Emacs exited with the same behaviour as explained in the
> > bug.
> 
> Do you see the same if you run Emacs as something other a daemon?
> 
> > I on the #gtk channel on what do and I got from ebassi that it is ok to
> > just call _exit.
> > He says it might be the client behaving wrong:
> > <ebassi> Thaodan: It could happen because the client made an invalid
> > request— Wayland mandates that the display server closes the connection
> > in that case
> We don't make raw Wayland requests anywhere, so it must be a bug in GTK.

What could be the way that GTK is used or is emacs with pgtk 99% a run of the 
mill gtk app?

> > <ebassi> And if you lose the socket then you'
> > <ebassi> you'll have to find the new one and reconnect
> > <ebassi> Thaodan: Only emacs does that
> > <ebassi> Pretty much literally
> > <Thaodan> "that"?
> > <ebassi> "app may run longer or before the compositor starts"
> > <ebassi> Because emacs is really a 1980s teletype app
> > <Thaodan> What does that change? calling _exit is not a solution.
> > <Thaodan> Lets assume the fault for this happening is emacs, what could
> > cause this?
> 
> Outdated information.  The PGTK port of Emacs doesn't do anything close
> to that, because GTK doesn't let us.
> 
> > <ebassi> Calling exit is perfectly acceptable: the display connection is
> > severed, and that can happen for multiple reasons, including the display
> > server going away
> > <ebassi> There's no "the display server is still running, but it closed
> > the
> > socket" mechanism for the toolkit to use
> 
> So why not use exit, which lets the atexit handlers run?

I don't know, can  someone ask? I feel like these people act like douches when 
some random person asks.

> > <ebassi> The socket got closed
> > <ebassi> The toolkit terminates
> > <ebassi> Thaodan: It could happen because the client made an invalid
> > request— Wayland mandates that the display server closes the connection
> > in that case <ebassi> Or the display server decided to kill the client
> > because it was unresponsive
> > <Thaodan> Why should the toolkit/lib call exit isn't there any better
> > mechanism to doing such a thing in glib or gtk for that matter?
> > <Thaodan> It would be better to not need any hacks to prevent gtk from
> > killing apps.
> > <ebassi> Thaodan: There is no such mechanism
> > <Thaodan> ebassi: OK so what's the idea behind using _exit as a mechanism,
> > doesn't that break any other app that has state so safe too? like for
> > example an office application that wants to safe it's data before going
> > down. <ebassi> I already told you
> > <ebassi> If the display connection is closed by the server, then there's
> > no
> > safe way to store the data
> 
> Store the data that is in Emacs core??  How did these people learn to
> write software?

I guess they did but learned that they are always right when there's an issue? 
Idk.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Bjoern Bidar <bjorn.bidar@thaodan.de> writes:

> What could be the way that GTK is used or is emacs with pgtk 99% a run of the 
> mill gtk app?

Emacs isn't a run-of-the-mill GTK app, but we only use what the
platform-independent parts of what the GTK developers expose.

> I don't know, can  someone ask? I feel like these people act like douches when 
> some random person asks.

They behave that way no matter who asks, which is why most people have
already given up trying to interact with them.  Simple example:
apparently, all the GTK developers have expensive monitors, so modern
font rendering techniques that improve font rendering on Full-HD
monitors have been deleted from GTK 4, and anyone who complains is given
some ridiculous excuse along the lines of "expensive monitors are the
future" and "subpixel font anti-aliasing is not adaptable to our
rendering pipeline", even though multiple people have already proposed
patches that demonstrate the opposite.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

The issue got picked up on Mastodon recently:
https://home.social/@ebassi@mastodon.social/109505829096414816

Someone reported a similar issue under X11 years earlier:
https://bugzilla.gnome.org/show_bug.cgi?id=646338

bug#56967: 29.0.50; Frequent crashes under Wayland

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

The issue got picked up on Mastodon recently:
https://home.social/@ebassi@mastodon.social/109505829096414816

Someone reported a similar issue under X11 years earlier:
https://bugzilla.gnome.org/show_bug.cgi?id=646338

bug#56967: 29.0.50; Frequent crashes under Wayland

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> The issue got picked up on Mastodon recently:
> https://home.social/@ebassi@mastodon.social/109505829096414816

That site doesn't work for me, could you please paste an excerpt here?

> Someone reported a similar issue under X11 years earlier:
> https://bugzilla.gnome.org/show_bug.cgi?id=646338

That applies only to the GDK X11 backend though, sadly.

Thanks.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu <luangruo@yahoo.com> writes:

> Björn Bidar <bjorn.bidar@thaodan.de> writes:
>
>> The issue got picked up on Mastodon recently:
>> https://home.social/@ebassi@mastodon.social/109505829096414816
>
> That site doesn't work for me, could you please paste an excerpt here?

This is my mastodon.el dump that should at some context, I added the
first post then my toot and Emanuel Ebassi's replies to me:

START mastdon.el dump

I do not like #Electron but I'm also not a fan of #Emacs. However, I appreciate the
self-deprecating humor.
https://cdn.fosstodon.org/media_attachments/files/109/501/742/682/624/996/original/749afb0111253dab.png
Aaron Toponce ⚛️:debian: (@atoponce@fosstodon.org) 2022-12-12 18:59:04

@atoponce @sotolf I think you get used to lisp, the language works just different to other
languages, after a time it's not as bad.
What usually bothers me is Emacs being single threaded quite often or using outdated
technologies such as #xembed which is now used to embedded #webkit.
The most annoying issue thou is #GTK doing funny stuff.
Like for example if you loose your display manager connection on #Wayland then GTK just
kills your application with _exit(). 
Björn (@thaodan) 2022-12-13 10:08:16 via Web
  ------------


@thaodan @atoponce @sotolf Terminating on display connection loss is recommended by the
Wayland protocol, because Wayland is not UDP: events don't get resent, and if the compositor
and the client don't agree on their state, you'll just going to crash later on. You could do
an orderly display connection drop while keeping the process alive, but a) only Emacs even
attempts this on X11 or Wayland; and b) it's not tested in toolkits because it's only needed
by Emacs 
Emmanuele Bassi (@ebassi@mastodon.social) 2022-12-13 12:12:26
  ------------


@ebassi @atoponce @sotolf Never argued against closing the display connection but using _
exit() instead of exit() to make sure the program can not react is bad at best or at worst
malicious.
This issue not only affects #Emacs but any program that wants to react on loosing the
display connection. 
Björn (@thaodan) 2022-12-13 13:32:46
  ------------


@thaodan @atoponce @sotolf GTK only uses `_exit()` on remote display close. It's kind of
intentional: if the *server* terminates the connection, then there's nothing to recover from
an application side. An application can only recover if it's the one that initiated the
closing of the display connection. 
Emmanuele Bassi (@ebassi@mastodon.social) 2022-12-13 13:39:09
  ------------


@ebassi @atoponce @sotolf So you decide for the application itself instead of letting the
application decide to what to do on `exit()`?
You say there's nothing to recover the applications opinion might be different. 
Björn (@thaodan) 2022-12-13 13:42:32
  ------------


@thaodan @atoponce @sotolf You cannot safely/reliably/portably do something after
server-side disconnection. We've been there with X11 first, and the same applies with
Wayland: https://bugzilla.gnome.org/show_bug.cgi?id=646338 
Emmanuele Bassi (@ebassi@mastodon.social) 2022-12-13 13:50:19 ✍ 2022-12-13 17:22:14
  ------------


@atoponce @sotolf For reference the #Debuggs entry for this:
https://lists.gnu.org/r/bug-gnu-emacs/2022-08/msg00305.html 
Björn (@thaodan) 2022-12-13 13:45:57
  ------------

END mastodon.el dump 

>> Someone reported a similar issue under X11 years earlier:
>> https://bugzilla.gnome.org/show_bug.cgi?id=646338
>
> That applies only to the GDK X11 backend though, sadly.

Worth to send a patch on this? I think it might be wort to talk other
GTk developers, e.g. the one that has done the change.

Br,

Björn

bug#56967: 29.0.50; Frequent crashes under Wayland

[Bjoern Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Also why should Emacs exit just when my display connection closes when it is 
run as server/daemon?

bug#56967: 29.0.50; Frequent crashes under Wayland

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Bjoern Bidar <bjorn.bidar@thaodan.de> writes:

> Also why should Emacs exit just when my display connection closes when it is 
> run as server/daemon?

Emacs can't do anything about it.  GDK (the library used by the GTK
toolkit for low-level display server interaction) automatically calls
_exit upon an IO error when writing or reading from a display
connection.

And please use "Reply All" to reply, or otherwise the conversation will
not be recorded on the bug tracker.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Bjoern Bidar <bjorn.bidar@thaodan.de> writes:

> Also I have to add that I'm using two screens, Emacs mentioned that is
> could be an issue when starting.

What message did Emacs print in that case?

bug#56967: 29.0.50; Frequent crashes under Wayland

[Bjoern Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Bjoern Bidar <bjorn.bidar@thaodan.de> writes:
> > Also I have to add that I'm using two screens, Emacs mentioned that is
> > could be an issue when starting.
> 
> What message did Emacs print in that case?

Aug 03 18:06:22 odin emacs[158852]: Due to a limitation in GTK 3, Emacs built 
with PGTK will simply exit when a
Aug 03 18:06:22 odin emacs[158852]: display connection is closed.  The problem 
is especially difficult to fix,
Aug 03 18:06:22 odin emacs[158852]: such that Emacs on Wayland with multiple 
displays is unlikely ever to be able
Aug 03 18:06:22 odin emacs[158852]: to survive disconnects.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Bjoern Bidar <bjorn.bidar@thaodan.de> writes:

>> Bjoern Bidar <bjorn.bidar@thaodan.de> writes:
>> > Also I have to add that I'm using two screens, Emacs mentioned that is
>> > could be an issue when starting.
>> 
>> What message did Emacs print in that case?
>
> Aug 03 18:06:22 odin emacs[158852]: Due to a limitation in GTK 3, Emacs built 
> with PGTK will simply exit when a
> Aug 03 18:06:22 odin emacs[158852]: display connection is closed.  The problem 
> is especially difficult to fix,
> Aug 03 18:06:22 odin emacs[158852]: such that Emacs on Wayland with multiple 
> displays is unlikely ever to be able
> Aug 03 18:06:22 odin emacs[158852]: to survive disconnects.

Right, but "display connection" here means a connection to the display
server (Wayland compositor.)  That isn't related to the number of
monitors connected to your machine.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Gavin Massingham]

I am also getting this frustrating bug, but *only*, it seems, if Emacs
server is running as a Systemd unit. I have not, so far, experienced a
crash if I launch the server in some other way.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Eli Zaretskii]

[Please CC the bug address, don't send private email just to me.]

> From: Bennet Yee (余仕斌) <bennet.yee@gmail.com>
> Date: Thu, 4 Aug 2022 11:12:44 -0700
> 
> FWIW I appeared to have just ran into this.  With emacs-gtk whenever I set mark and move down a line
> (which would highlight the region) emacs would crash:
> 
> Backtrace:
> emacs(+0x150ed5)[0x55cb9e339ed5]
> emacs(+0x4aa38)[0x55cb9e233a38]
> emacs(+0x4af22)[0x55cb9e233f22]
> emacs(+0x14eefd)[0x55cb9e337efd]
> emacs(+0x14ef7d)[0x55cb9e337f7d]
> /lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7f068ca42520]
> /lib/x86_64-linux-gnu/libX11.so.6(XVisualIDFromVisual+0x4)[0x7f068e1f5f24]
> /lib/x86_64-linux-gnu/libgdk-3.so.0(gdk_x11_window_foreign_new_for_display+0x18e)[0x7f068e979a2e]
> /lib/x86_64-linux-gnu/libgdk-3.so.0(+0x6b9f8)[0x7f068e9649f8]
> /lib/x86_64-linux-gnu/libgdk-3.so.0(+0x6d191)[0x7f068e966191]
> /lib/x86_64-linux-gnu/libgdk-3.so.0(+0x70d28)[0x7f068e969d28]
> /lib/x86_64-linux-gnu/libgdk-3.so.0(gdk_display_get_event+0x89)[0x7f068e92fa99]
> /lib/x86_64-linux-gnu/libgdk-3.so.0(+0x70f46)[0x7f068e969f46]
> /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x26b)[0x7f068e37ed1b]
> /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0xaa6f8)[0x7f068e3d36f8]
> /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x33)[0x7f068e37c3c3]
> /lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_main_iteration+0x19)[0x7f068ec48d99]
> emacs(+0x105073)[0x55cb9e2ee073]
> emacs(+0x13d482)[0x55cb9e326482]
> emacs(+0x13da75)[0x55cb9e326a75]
> emacs(+0x1ba1b5)[0x55cb9e3a31b5]
> emacs(+0xb55ec)[0x55cb9e29e5ec]
> emacs(+0x7bac4)[0x55cb9e264ac4]
> emacs(+0x8b9e8)[0x55cb9e2749e8]
> emacs(+0x90783)[0x55cb9e279783]
> emacs(+0xa5611)[0x55cb9e28e611]
> emacs(+0xa8096)[0x55cb9e291096]
> emacs(+0x1b30dc)[0x55cb9e39c0dc]
> emacs(+0x94363)[0x55cb9e27d363]
> emacs(+0x140ef3)[0x55cb9e329ef3]
> emacs(+0x143bea)[0x55cb9e32cbea]
> emacs(+0x14538c)[0x55cb9e32e38c]
> emacs(+0x1b3047)[0x55cb9e39c047]
> emacs(+0x136190)[0x55cb9e31f190]
> emacs(+0x1b2f89)[0x55cb9e39bf89]
> emacs(+0x13611e)[0x55cb9e31f11e]
> emacs(+0x13b72a)[0x55cb9e32472a]
> emacs(+0x13ba69)[0x55cb9e324a69]
> emacs(+0x52aca)[0x55cb9e23baca]
> /lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7f068ca29d90]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7f068ca29e40]
> ...

Thanks, but this kind of backtrace can only be interpreted on your
system.  Please either show the results of running addr2line on it (as
explained in the node "Crashing" of the Emacs manual), or run Emacs
under GDB and produce a human-readable backtrace from there.

bug#56967: 29.0.50; Frequent crashes under Wayland

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Bennet Yee (余仕斌) <bennet.yee@gmail.com>
>> Date: Thu, 4 Aug 2022 11:12:44 -0700
>> 
>> FWIW I appeared to have just ran into this.  With emacs-gtk whenever I set mark and move down a line
>> (which would highlight the region) emacs would crash:
>> 
>> Backtrace:
>> emacs(+0x150ed5)[0x55cb9e339ed5]
>> emacs(+0x4aa38)[0x55cb9e233a38]
>> emacs(+0x4af22)[0x55cb9e233f22]
>> emacs(+0x14eefd)[0x55cb9e337efd]
>> emacs(+0x14ef7d)[0x55cb9e337f7d]
>> /lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7f068ca42520]
>> /lib/x86_64-linux-gnu/libX11.so.6(XVisualIDFromVisual+0x4)[0x7f068e1f5f24]
>> /lib/x86_64-linux-gnu/libgdk-3.so.0(gdk_x11_window_foreign_new_for_display+0x18e)[0x7f068e979a2e]
>> /lib/x86_64-linux-gnu/libgdk-3.so.0(+0x6b9f8)[0x7f068e9649f8]
>> /lib/x86_64-linux-gnu/libgdk-3.so.0(+0x6d191)[0x7f068e966191]
>> /lib/x86_64-linux-gnu/libgdk-3.so.0(+0x70d28)[0x7f068e969d28]
>> /lib/x86_64-linux-gnu/libgdk-3.so.0(gdk_display_get_event+0x89)[0x7f068e92fa99]
>> /lib/x86_64-linux-gnu/libgdk-3.so.0(+0x70f46)[0x7f068e969f46]
>> /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x26b)[0x7f068e37ed1b]
>> /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0xaa6f8)[0x7f068e3d36f8]
>> /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x33)[0x7f068e37c3c3]
>> /lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_main_iteration+0x19)[0x7f068ec48d99]
>> emacs(+0x105073)[0x55cb9e2ee073]
>> emacs(+0x13d482)[0x55cb9e326482]
>> emacs(+0x13da75)[0x55cb9e326a75]
>> emacs(+0x1ba1b5)[0x55cb9e3a31b5]
>> emacs(+0xb55ec)[0x55cb9e29e5ec]
>> emacs(+0x7bac4)[0x55cb9e264ac4]
>> emacs(+0x8b9e8)[0x55cb9e2749e8]
>> emacs(+0x90783)[0x55cb9e279783]
>> emacs(+0xa5611)[0x55cb9e28e611]
>> emacs(+0xa8096)[0x55cb9e291096]
>> emacs(+0x1b30dc)[0x55cb9e39c0dc]
>> emacs(+0x94363)[0x55cb9e27d363]
>> emacs(+0x140ef3)[0x55cb9e329ef3]
>> emacs(+0x143bea)[0x55cb9e32cbea]
>> emacs(+0x14538c)[0x55cb9e32e38c]
>> emacs(+0x1b3047)[0x55cb9e39c047]
>> emacs(+0x136190)[0x55cb9e31f190]
>> emacs(+0x1b2f89)[0x55cb9e39bf89]
>> emacs(+0x13611e)[0x55cb9e31f11e]
>> emacs(+0x13b72a)[0x55cb9e32472a]
>> emacs(+0x13ba69)[0x55cb9e324a69]
>> emacs(+0x52aca)[0x55cb9e23baca]
>> /lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7f068ca29d90]
>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7f068ca29e40]
>> ...

Bennet Lee, do you have a clipboard manager installed on your system?
I'm going to guess changing the region caused ownership to be asserted
over the primary selection, in turn causing the clipboard manager to
send Emacs a selection request from an InputOnly window.  GDK then tried
to create a wrapper around that window, but crashed because the visual
of the InputOnly window could not be found in its own client-side record
of GDK visual objects.

This chain of events should only be possible on PGTK builds running on
X.  In that case, you should simply refrain from using PGTK on X.  This
problem and many others cause us to not support running such builds on
X.

If not, please see if the following change is sufficient to fix the
problem:

diff --git a/src/xterm.c b/src/xterm.c
index 4bbcfb0e59..5bc755b41f 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -17613,6 +17613,12 @@ handle_one_xevent (struct x_display_info *dpyinfo,
 	    if (eventp->target == dpyinfo->Xatom_XmTRANSFER_FAILURE)
 	      x_dnd_action = None;
 	  }
+
+	/* Selection requests for the widget should never reach
+	   GDK.  */
+#ifdef USE_GTK
+	*finish = X_EVENT_DROP;
+#endif
       }
       break;