GNU bug report logs - #31547
25.3; Core dump: g_main_context_prepare() called recursively from within a source's check() or prepare() member.

Previous Next

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

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

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

From: marc <at> budabe.eu
To: bug-gnu-emacs <at> gnu.org
Subject: 25.3;
 Core dump: g_main_context_prepare() called recursively from within a
 source's check() or prepare() member.
Date: Tue, 22 May 2018 06:45:31 +0200

Actions:
- Start Wanderlust package
- Open the .Sent Folder (most likely dependend on its concrete contents)
--> first core dump of Emacs in years (here reproducible)



(emacs:11477): GLib-WARNING **: 06:38:49.685: g_main_context_prepare() called recursively from within a source's check() or prepare() member.

(emacs:11477): GLib-WARNING **: 06:38:49.685: g_main_context_check() called recursively from within a source's check() or prepare() member.

Backtrace:
emacs[0x508b3f]
emacs[0x4ee96c]
emacs[0x508bf4]
emacs[0x44f9ab]
emacs[0x45213a]
emacs[0x5a3442]
emacs[0x5aae45]
emacs[0x4ee748]
emacs[0x4bd65a]
emacs[0x4c1adb]
emacs[0x4c1b6b]
/usr/lib/libX11.so.6(_XError+0x11d)[0x7fa4ce26b6ed]
/usr/lib/libX11.so.6(+0x41617)[0x7fa4ce268617]
/usr/lib/libX11.so.6(+0x416d5)[0x7fa4ce2686d5]
/usr/lib/libX11.so.6(_XEventsQueued+0x55)[0x7fa4ce268fd5]
/usr/lib/libX11.so.6(XPending+0x57)[0x7fa4ce25aca7]
/usr/lib/libgdk-3.so.0(+0x66f6f)[0x7fa4cfa89f6f]
/usr/lib/libglib-2.0.so.0(g_main_context_prepare+0x1c9)[0x7fa4ce9d5a49]
/usr/lib/libglib-2.0.so.0(+0x4c44e)[0x7fa4ce9d644e]
/usr/lib/libglib-2.0.so.0(g_main_context_pending+0x29)[0x7fa4ce9d65e9]
/usr/lib/libgtk-3.so.0(gtk_events_pending+0xf)[0x7fa4cff47e3f]
emacs[0x4be039]
emacs[0x4f5929]
emacs[0x4f5fe5]
emacs[0x5cc0b4]
emacs[0x57bba4]
emacs[0x5cee4b]
emacs[0x5cf0d3]
emacs[0x5cf3ec]
emacs[0x43eeab]
emacs[0x440661]
emacs[0x442f1a]
emacs[0x449b96]
emacs[0x46dd65]
emacs[0x563d0e]
emacs[0x59cff4]
emacs[0x565f80]
emacs[0x563b7b]
emacs[0x563dd9]
emacs[0x56291d]
emacs[0x5633b0]
...

[3]+  Aborted                 (core dumped) emacs


In GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
 of 2018-05-09 built on arojas
Windowing system distributor 'The X.Org Foundation', version 11.0.12000000
Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-modules
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
 -fno-plt' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES

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

Major mode: Fundamental

Minor modes in effect:
  async-bytecomp-package-mode: t
  savehist-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Debug (ox-odt): Trying /usr/share/emacs/25.3/etc/styles/... [2 times]
Debug (ox-odt): Trying /usr/share/emacs/25.3/lisp/org/etc/styles/...
Debug (ox-odt): Trying /usr/share/emacs/25.3/etc/org/...
Debug (ox-odt): Using styles under /usr/share/emacs/25.3/etc/org/
Debug (ox-odt): Searching for OpenDocument schema files...
Debug (ox-odt): Trying /usr/share/emacs/25.3/etc/schema/...
Debug (ox-odt): No OpenDocument schema files installed
Problems while trying to load export back-end ‘confluence’
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Load-path shadows:
~/site-lisp/php-mode hides /home/mwkuster/.emacs.d/elpa/php-mode-20171107.826/php-mode
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-player-mpd hides /usr/share/emacs/site-lisp/emms/emms-player-mpd
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-last-played hides /usr/share/emacs/site-lisp/emms/emms-last-played
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-url hides /usr/share/emacs/site-lisp/emms/emms-url
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-mode-line hides /usr/share/emacs/site-lisp/emms/emms-mode-line
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-info-ogginfo hides /usr/share/emacs/site-lisp/emms/emms-info-ogginfo
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/later-do hides /usr/share/emacs/site-lisp/emms/later-do
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-volume-pulse hides /usr/share/emacs/site-lisp/emms/emms-volume-pulse
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-show-all hides /usr/share/emacs/site-lisp/emms/emms-show-all
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-librefm-scrobbler hides /usr/share/emacs/site-lisp/emms/emms-librefm-scrobbler
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-compat hides /usr/share/emacs/site-lisp/emms/emms-compat
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-info hides /usr/share/emacs/site-lisp/emms/emms-info
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-i18n hides /usr/share/emacs/site-lisp/emms/emms-i18n
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-player-vlc hides /usr/share/emacs/site-lisp/emms/emms-player-vlc
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-volume hides /usr/share/emacs/site-lisp/emms/emms-volume
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-score hides /usr/share/emacs/site-lisp/emms/emms-score
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-stream-info hides /usr/share/emacs/site-lisp/emms/emms-stream-info
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-mark hides /usr/share/emacs/site-lisp/emms/emms-mark
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-streams hides /usr/share/emacs/site-lisp/emms/emms-streams
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms hides /usr/share/emacs/site-lisp/emms/emms
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-browser hides /usr/share/emacs/site-lisp/emms/emms-browser
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-player-mpg321-remote hides /usr/share/emacs/site-lisp/emms/emms-player-mpg321-remote
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-tag-editor hides /usr/share/emacs/site-lisp/emms/emms-tag-editor
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-lyrics hides /usr/share/emacs/site-lisp/emms/emms-lyrics
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-playlist-sort hides /usr/share/emacs/site-lisp/emms/emms-playlist-sort
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-metaplaylist-mode hides /usr/share/emacs/site-lisp/emms/emms-metaplaylist-mode
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-player-simple hides /usr/share/emacs/site-lisp/emms/emms-player-simple
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-source-playlist hides /usr/share/emacs/site-lisp/emms/emms-source-playlist
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-source-file hides /usr/share/emacs/site-lisp/emms/emms-source-file
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-info-metaflac hides /usr/share/emacs/site-lisp/emms/emms-info-metaflac
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-volume-amixer hides /usr/share/emacs/site-lisp/emms/emms-volume-amixer
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-cache hides /usr/share/emacs/site-lisp/emms/emms-cache
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/jack hides /usr/share/emacs/site-lisp/emms/jack
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-librefm-stream hides /usr/share/emacs/site-lisp/emms/emms-librefm-stream
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-info-libtag hides /usr/share/emacs/site-lisp/emms/emms-info-libtag
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-bookmarks hides /usr/share/emacs/site-lisp/emms/emms-bookmarks
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-history hides /usr/share/emacs/site-lisp/emms/emms-history
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-player-mplayer hides /usr/share/emacs/site-lisp/emms/emms-player-mplayer
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-player-xine hides /usr/share/emacs/site-lisp/emms/emms-player-xine
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-mode-line-icon hides /usr/share/emacs/site-lisp/emms/emms-mode-line-icon
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-playlist-mode hides /usr/share/emacs/site-lisp/emms/emms-playlist-mode
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-playing-time hides /usr/share/emacs/site-lisp/emms/emms-playing-time
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-setup hides /usr/share/emacs/site-lisp/emms/emms-setup
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-maint hides /usr/share/emacs/site-lisp/emms/emms-maint
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-info-mp3info hides /usr/share/emacs/site-lisp/emms/emms-info-mp3info
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-playlist-limit hides /usr/share/emacs/site-lisp/emms/emms-playlist-limit
/home/mwkuster/.emacs.d/elpa/emms-20171115.1149/emms-cue hides /usr/share/emacs/site-lisp/emms/emms-cue
/home/mwkuster/.emacs.d/elpa/flim-20161210.1728/md4 hides /usr/share/emacs/25.3/lisp/md4
/home/mwkuster/.emacs.d/elpa/flim-20161210.1728/hex-util hides /usr/share/emacs/25.3/lisp/hex-util
~/site-lisp/rst hides /usr/share/emacs/25.3/lisp/textmodes/rst
/home/mwkuster/.emacs.d/elpa/scala-mode-20170802.432/ob-scala hides /usr/share/emacs/25.3/lisp/org/ob-scala
/home/mwkuster/.emacs.d/elpa/flim-20161210.1728/sasl-ntlm hides /usr/share/emacs/25.3/lisp/net/sasl-ntlm
/home/mwkuster/.emacs.d/elpa/flim-20161210.1728/sasl hides /usr/share/emacs/25.3/lisp/net/sasl
/home/mwkuster/.emacs.d/elpa/flim-20161210.1728/hmac-md5 hides /usr/share/emacs/25.3/lisp/net/hmac-md5
/home/mwkuster/.emacs.d/elpa/flim-20161210.1728/sasl-digest hides /usr/share/emacs/25.3/lisp/net/sasl-digest
/home/mwkuster/.emacs.d/elpa/flim-20161210.1728/hmac-def hides /usr/share/emacs/25.3/lisp/net/hmac-def
/home/mwkuster/.emacs.d/elpa/flim-20161210.1728/ntlm hides /usr/share/emacs/25.3/lisp/net/ntlm
/home/mwkuster/.emacs.d/elpa/flim-20161210.1728/sasl-cram hides /usr/share/emacs/25.3/lisp/net/sasl-cram
/home/mwkuster/.emacs.d/elpa/seq-2.20/seq hides /usr/share/emacs/25.3/lisp/emacs-lisp/seq
/home/mwkuster/.emacs.d/elpa/let-alist-1.0.5/let-alist hides /usr/share/emacs/25.3/lisp/emacs-lisp/let-alist

Features:
(shadow mail-extr emacsbug sendmail 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 emms-info-libtag emms-librefm-stream emms-librefm-scrobbler
emms-playlist-limit emms-volume emms-volume-amixer emms-i18n
emms-history emms-score emms-stream-info emms-metaplaylist-mode
emms-bookmarks emms-cue emms-mode-line-icon emms-browser sort
emms-playlist-sort emms-last-played emms-player-xine emms-player-mpd
emms-playing-time emms-lyrics emms-url emms-streams emms-show-all
emms-tag-editor emms-mark emms-mode-line emms-cache emms-info-ogginfo
emms-info-mp3info emms-info later-do emms-playlist-mode emms-player-vlc
emms-player-mplayer emms-player-simple emms-source-playlist
emms-source-file locate emms-setup emms emms-compat ruby-electric
inf-ruby ruby-mode smie clojure-mode align org-ref org-ref-helm-bibtex
org-ref-helm helm-utils helm-bibtex bibtex-completion biblio
biblio-download biblio-dissemin biblio-hal biblio-dblp biblio-crossref
biblio-arxiv timezone biblio-doi biblio-core let-alist url-queue ido
hl-line helm-net browse-url xml helm-help helm helm-source eieio-compat
helm-multi-match helm-lib helm-config helm-easymenu async-bytecomp async
org-ref-core warnings edmacro kmacro reftex-cite reftex reftex-vars
parsebib ox-latex ox-icalendar ox-html ox-ascii ox-publish ox
org-ref-glossary org-ref-bibtex org-ref-citeproc org-element message
idna dired rfc822 mml mml-sec epg mm-decode mm-bodies mm-encode
mailabbrev gmm-utils mailheader key-chord hydra lv doi-utils
org-ref-utils org-ref-pdf pdf-tools compile cus-edit cus-start cus-load
wid-edit pdf-view bookmark pp jka-compr pdf-cache pdf-info tq pdf-util
image-mode url-http tls gnutls url-auth mail-parse rfc2231 rfc2047
rfc2045 ietf-drums url-gw org-bibtex bibtex f ob-sparql sparql-mode
ob-elasticsearch s es-parse dash org org-macro org-footnote
org-pcomplete pcomplete org-list org-faces org-entities noutline outline
easy-mmode org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table
ob-exp org-src ob-keys ob-comint comint ansi-color ring ob-core ob-eval
org-compat org-macs org-loaddefs format-spec find-func cal-menu calendar
cal-loaddefs es-mode subr-x request mail-utils url-handlers url
url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util url-parse auth-source cl-seq eieio eieio-core
cl-macs gnus-util mm-util help-fns mail-prsvr password-cache url-vars
mailcap js advice sgml-mode json map imenu thingatpt cc-mode cc-fonts
cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
server ispell finder-inf info package epg-config seq byte-opt gv
bytecomp byte-compile cl-extra help-mode easymenu cconv cl-loaddefs
pcase cl-lib savehist time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
dbusbind inotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 557204 18218)
 (symbols 48 48952 0)
 (miscs 40 626 281)
 (strings 32 171666 24161)
 (string-bytes 1 5777965)
 (vectors 16 52691)
 (vector-slots 8 1677549 183259)
 (floats 8 429 53)
 (intervals 56 800 0)
 (buffers 976 19))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: marc <at> budabe.eu
Cc: 31547 <at> debbugs.gnu.org
Subject: Re: bug#31547: 25.3;
 Core dump: g_main_context_prepare() called recursively from within a
 source's check() or prepare() member.
Date: Tue, 22 May 2018 19:34:23 +0300

> From: marc <at> budabe.eu
> Date: Tue, 22 May 2018 06:45:31 +0200
> 
> Actions:
> - Start Wanderlust package
> - Open the .Sent Folder (most likely dependend on its concrete contents)
> --> first core dump of Emacs in years (here reproducible)
> 
> 
> 
> (emacs:11477): GLib-WARNING **: 06:38:49.685: g_main_context_prepare() called recursively from within a source's check() or prepare() member.
> 
> (emacs:11477): GLib-WARNING **: 06:38:49.685: g_main_context_check() called recursively from within a source's check() or prepare() member.
> 
> Backtrace:
> emacs[0x508b3f]
> emacs[0x4ee96c]

Thanks, but this backtrace can only be interpreted on the system where
it was produced.  So please use the procedure described in the node
"Crashing" of the Emacs manual to convert the addresses to file names,
function names, and source line numbers.

If you can afford that, please try the latest release candidate of
Emacs 26.1, it's available from alpha.gnu.org.  It could be that this
problem was already fixed.

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

From: Marc Wilhelm Küster <marc <at> budabe.eu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31547 <at> debbugs.gnu.org, marc <at> budabe.eu
Subject: Re: bug#31547: 25.3;
 Core dump: g_main_context_prepare() called recursively from within
 a	source's check() or prepare() member.
Date: Tue, 22 May 2018 21:43:36 +0200

[Message part 1 (text/plain, inline)]

Dear Eli Zaretskii,

thanks for your reply and no problem, here we go, assuming the script you've been speaking of is https://www.gnu.org/software/emacs/manual/html_node/emacs/Crashing.html

The file contains quite a number of question marks, though

The emacs in question is incidentally the current emacs version in Archlinux

Best regards,

Marc

[bt (application/octet-stream, attachment)]

[Message part 3 (text/plain, inline)]

On Tue, 22 May 2018 18:34:23 +0200,
Eli Zaretskii wrote:
> 
> > From: marc <at> budabe.eu
> > Date: Tue, 22 May 2018 06:45:31 +0200
> > 
> > Actions:
> > - Start Wanderlust package
> > - Open the .Sent Folder (most likely dependend on its concrete contents)
> > --> first core dump of Emacs in years (here reproducible)
> > 
> > 
> > 
> > (emacs:11477): GLib-WARNING **: 06:38:49.685: g_main_context_prepare() called recursively from within a source's check() or prepare() member.
> > 
> > (emacs:11477): GLib-WARNING **: 06:38:49.685: g_main_context_check() called recursively from within a source's check() or prepare() member.
> > 
> > Backtrace:
> > emacs[0x508b3f]
> > emacs[0x4ee96c]
> 
> Thanks, but this backtrace can only be interpreted on the system where
> it was produced.  So please use the procedure described in the node
> "Crashing" of the Emacs manual to convert the addresses to file names,
> function names, and source line numbers.
> 
> If you can afford that, please try the latest release candidate of
> Emacs 26.1, it's available from alpha.gnu.org.  It could be that this
> problem was already fixed.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Marc Wilhelm Küster <marc <at> budabe.eu>
Cc: 31547 <at> debbugs.gnu.org
Subject: Re: bug#31547: 25.3;
 Core dump: g_main_context_prepare() called recursively from within
 a	source's check() or prepare() member.
Date: Wed, 23 May 2018 05:29:40 +0300

> Date: Tue, 22 May 2018 21:43:36 +0200
> From: Marc Wilhelm Küster <marc <at> budabe.eu>
> Cc: 31547 <at> debbugs.gnu.org,
> 	marc <at> budabe.eu
> 
> thanks for your reply and no problem, here we go, assuming the script you've been speaking of is https://www.gnu.org/software/emacs/manual/html_node/emacs/Crashing.html
> 
> The file contains quite a number of question marks, though

That's because your Emacs binary is stripped of debugging symbols.  Is
there perhaps an auxiliary distribution with those symbols as separate
files?  If so, could you please install that and repeat what you've
done?

Thanks.

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

From: Marc Wilhelm Küster <marc <at> budabe.eu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31547 <at> debbugs.gnu.org,
 Marc Wilhelm Küster <marc <at> budabe.eu>
Subject: Re: bug#31547: 25.3;
 Core dump: g_main_context_prepare() called recursively from within
 a	source's check() or prepare() member.
Date: Wed, 23 May 2018 07:10:00 +0200

On Wed, 23 May 2018 04:29:40 +0200,
Eli Zaretskii wrote:
> 
> > Date: Tue, 22 May 2018 21:43:36 +0200
> > From: Marc Wilhelm Küster <marc <at> budabe.eu>
> > Cc: 31547 <at> debbugs.gnu.org,
> > 	marc <at> budabe.eu
> > 
> > thanks for your reply and no problem, here we go, assuming the script you've been speaking of is https://www.gnu.org/software/emacs/manual/html_node/emacs/Crashing.html
> > 
> > The file contains quite a number of question marks, though
> 


Thanks!

> That's because your Emacs binary is stripped of debugging symbols.  Is
> there perhaps an auxiliary distribution with those symbols as separate
> files?  If so, could you please install that and repeat what you've
> done?
> 
Not to my knowledge out of the box, I'm afraid. I could perhaps configure and compile my own version of the emacs package with debuging included, but I'd need some time to study how that might work under Archlinux.

Are there alternatives?

Best regards,

Marc

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Marc Wilhelm Küster <marc <at> budabe.eu>
Cc: 31547 <at> debbugs.gnu.org
Subject: Re: bug#31547: 25.3;
 Core dump: g_main_context_prepare() called recursively from within
 a	source's check() or prepare() member.
Date: Wed, 23 May 2018 18:18:47 +0300

> Date: Wed, 23 May 2018 07:10:00 +0200
> From: Marc Wilhelm Küster <marc <at> budabe.eu>
> Cc: Marc Wilhelm Küster <marc <at> budabe.eu>,
> 	31547 <at> debbugs.gnu.org
> 
> > That's because your Emacs binary is stripped of debugging symbols.  Is
> > there perhaps an auxiliary distribution with those symbols as separate
> > files?  If so, could you please install that and repeat what you've
> > done?
> > 
> Not to my knowledge out of the box, I'm afraid. I could perhaps configure and compile my own version of the emacs package with debuging included, but I'd need some time to study how that might work under Archlinux.

If you do decide to build your own Emacs, I suggest to build version
26.1, because it's quite possible this problem is fixed there (and if
it isn't, it becomes much more urgent).

> Are there alternatives?

Not that I know of.

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

From: Marc Wilhelm Küster <marc <at> budabe.eu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31547 <at> debbugs.gnu.org,
 Marc Wilhelm Küster <marc <at> budabe.eu>
Subject: Re: bug#31547: 25.3;
 Core dump: g_main_context_prepare() called recursively from within
 a	source's check() or prepare() member.
Date: Tue, 29 May 2018 07:12:09 +0200

[Message part 1 (text/plain, inline)]

Dear Eli,

tonight the emacs delivered with Archlinux has updated itself to GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2018-05-29. You might be interested that the crash persists (scenario to provoke it unchanged).

I attach you the backtrace (before and after processing with sed and addr2line) and will look into options to get an emacs version with debugging symbols (might take a moment, unfortunately).

Best regards,

Marc

[bt.txt (text/plain, inline)]

(emacs:14478): GLib-WARNING **: 06:47:47.100: g_main_context_prepare() called recursively from within a source's check() or prepare() member.

(emacs:14478): GLib-WARNING **: 06:47:47.101: g_main_context_check() called recursively from within a source's check() or prepare() member.

Backtrace:
emacs[0x50f76f]
emacs[0x4f4aa2]
emacs[0x50f824]
emacs[0x452e6b]
emacs[0x4555f4]
emacs[0x5af552]
emacs[0x5b7585]
emacs[0x4f4848]
emacs[0x4c090a]
emacs[0x4c484b]
emacs[0x4c48db]
/usr/lib/libX11.so.6(_XError+0x11d)[0x7f329f7076ed]
/usr/lib/libX11.so.6(+0x41617)[0x7f329f704617]
/usr/lib/libX11.so.6(+0x416d5)[0x7f329f7046d5]
/usr/lib/libX11.so.6(_XEventsQueued+0x55)[0x7f329f704fd5]
/usr/lib/libX11.so.6(XPending+0x57)[0x7f329f6f6ca7]
/usr/lib/libgdk-3.so.0(+0x66f6f)[0x7f32a0f25f6f]
/usr/lib/libglib-2.0.so.0(g_main_context_prepare+0x1c9)[0x7f329fe71a49]
/usr/lib/libglib-2.0.so.0(+0x4c44e)[0x7f329fe7244e]
/usr/lib/libglib-2.0.so.0(g_main_context_pending+0x29)[0x7f329fe725e9]
/usr/lib/libgtk-3.so.0(gtk_events_pending+0xf)[0x7f32a13e3e3f]
emacs[0x4c1339]
emacs[0x4fbeb9]
emacs[0x4fc585]
emacs[0x5dd884]
emacs[0x5861e4]
emacs[0x5e03db]
emacs[0x5e0663]
emacs[0x5e097c]
emacs[0x443ce4]
emacs[0x440441]
emacs[0x44583a]
emacs[0x445a6d]
emacs[0x470b81]
emacs[0x56cd1d]
emacs[0x5a8ff1]
emacs[0x56f684]
emacs[0x56cc9b]
emacs[0x56cd39]
emacs[0x56c2fd]
emacs[0x56c430]
...

[bt2.txt (text/plain, inline)]

XSetWMNormalHints at ??:?
XSetWMNormalHints at ??:?
XSetWMNormalHints at ??:?
?? ??:0
?? ??:0
error at ??:?
error at ??:?
XSetWMNormalHints at ??:?
?? ??:0
?? ??:0
?? ??:0
?? ??:0
?? ??:0
?? ??:0
?? ??:0
?? ??:0
?? ??:0
?? ??:0
?? ??:0
?? ??:0
?? ??:0
?? ??:0
XSetWMNormalHints at ??:?
XSetWMNormalHints at ??:?
error at ??:?
error at ??:?
error at ??:?
error at ??:?
error at ??:?
?? ??:0
?? ??:0
?? ??:0
?? ??:0
?? ??:0
re_compile_pattern at ??:?
error at ??:?
error at ??:?
re_compile_pattern at ??:?
re_compile_pattern at ??:?
re_compile_pattern at ??:?
re_compile_pattern at ??:?

[Message part 4 (text/plain, inline)]

On Wed, 23 May 2018 17:18:47 +0200,
Eli Zaretskii wrote:
> 
> > Date: Wed, 23 May 2018 07:10:00 +0200
> > From: Marc Wilhelm Küster <marc <at> budabe.eu>
> > Cc: Marc Wilhelm Küster <marc <at> budabe.eu>,
> > 	31547 <at> debbugs.gnu.org
> > 
> > > That's because your Emacs binary is stripped of debugging symbols.  Is
> > > there perhaps an auxiliary distribution with those symbols as separate
> > > files?  If so, could you please install that and repeat what you've
> > > done?
> > > 
> > Not to my knowledge out of the box, I'm afraid. I could perhaps configure and compile my own version of the emacs package with debuging included, but I'd need some time to study how that might work under Archlinux.
> 
> If you do decide to build your own Emacs, I suggest to build version
> 26.1, because it's quite possible this problem is fixed there (and if
> it isn't, it becomes much more urgent).
> 
> > Are there alternatives?
> 
> Not that I know of.

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

From: Marc Wilhelm Küster <marc <at> budabe.eu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31547 <at> debbugs.gnu.org
Subject: Re: bug#31547: 25.3;
 Core dump: g_main_context_prepare() called recursively from within
 a	source's check() or prepare() member.
Date: Sat, 02 Jun 2018 18:25:39 +0200

[Message part 1 (text/plain, inline)]

Hello,

in order to get a more meaningful backtrace I've compiled emacs 26.1 directly from its source (source directly downloaded from http://mirror.switch.ch/ftp/mirror/gnu/emacs/emacs-26.1.tar.xz)

The crash remains fully reproducible. I attach you the backtraces. Of yourse, I'm at your disposal for any additional information you may need

Best regards,

Marc

[backtrace.orig (application/octet-stream, attachment)]

[backtrace.addr2line (application/octet-stream, attachment)]

[Message part 4 (text/plain, inline)]

On Tue, 29 May 2018 07:12:09 +0200,
Marc Wilhelm Küster wrote:
> 
> [1  <text/plain; US-ASCII (7bit)>]
> Dear Eli,
> 
> tonight the emacs delivered with Archlinux has updated itself to GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2018-05-29. You might be interested that the crash persists (scenario to provoke it unchanged).
> 
> I attach you the backtrace (before and after processing with sed and addr2line) and will look into options to get an emacs version with debugging symbols (might take a moment, unfortunately).
> 
> Best regards,
> 
> Marc
> 
> [2 bt.txt <text/plain; UTF-8 (base64)>]
> (emacs:14478): GLib-WARNING **: 06:47:47.100: g_main_context_prepare() called recursively from within a source's check() or prepare() member.
> 
> (emacs:14478): GLib-WARNING **: 06:47:47.101: g_main_context_check() called recursively from within a source's check() or prepare() member.
> 
> Backtrace:
> emacs[0x50f76f]
> emacs[0x4f4aa2]
> emacs[0x50f824]
> emacs[0x452e6b]
> emacs[0x4555f4]
> emacs[0x5af552]
> emacs[0x5b7585]
> emacs[0x4f4848]
> emacs[0x4c090a]
> emacs[0x4c484b]
> emacs[0x4c48db]
> /usr/lib/libX11.so.6(_XError+0x11d)[0x7f329f7076ed]
> /usr/lib/libX11.so.6(+0x41617)[0x7f329f704617]
> /usr/lib/libX11.so.6(+0x416d5)[0x7f329f7046d5]
> /usr/lib/libX11.so.6(_XEventsQueued+0x55)[0x7f329f704fd5]
> /usr/lib/libX11.so.6(XPending+0x57)[0x7f329f6f6ca7]
> /usr/lib/libgdk-3.so.0(+0x66f6f)[0x7f32a0f25f6f]
> /usr/lib/libglib-2.0.so.0(g_main_context_prepare+0x1c9)[0x7f329fe71a49]
> /usr/lib/libglib-2.0.so.0(+0x4c44e)[0x7f329fe7244e]
> /usr/lib/libglib-2.0.so.0(g_main_context_pending+0x29)[0x7f329fe725e9]
> /usr/lib/libgtk-3.so.0(gtk_events_pending+0xf)[0x7f32a13e3e3f]
> emacs[0x4c1339]
> emacs[0x4fbeb9]
> emacs[0x4fc585]
> emacs[0x5dd884]
> emacs[0x5861e4]
> emacs[0x5e03db]
> emacs[0x5e0663]
> emacs[0x5e097c]
> emacs[0x443ce4]
> emacs[0x440441]
> emacs[0x44583a]
> emacs[0x445a6d]
> emacs[0x470b81]
> emacs[0x56cd1d]
> emacs[0x5a8ff1]
> emacs[0x56f684]
> emacs[0x56cc9b]
> emacs[0x56cd39]
> emacs[0x56c2fd]
> emacs[0x56c430]
> ...
> 
> 
> [3 bt2.txt <text/plain; UTF-8 (base64)>]
> XSetWMNormalHints at ??:?
> XSetWMNormalHints at ??:?
> XSetWMNormalHints at ??:?
> ?? ??:0
> ?? ??:0
> error at ??:?
> error at ??:?
> XSetWMNormalHints at ??:?
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> XSetWMNormalHints at ??:?
> XSetWMNormalHints at ??:?
> error at ??:?
> error at ??:?
> error at ??:?
> error at ??:?
> error at ??:?
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> re_compile_pattern at ??:?
> error at ??:?
> error at ??:?
> re_compile_pattern at ??:?
> re_compile_pattern at ??:?
> re_compile_pattern at ??:?
> re_compile_pattern at ??:?
> [4  <text/plain; ISO-8859-1 (quoted-printable)>]
> 
> 
> On Wed, 23 May 2018 17:18:47 +0200,
> Eli Zaretskii wrote:
> > 
> > > Date: Wed, 23 May 2018 07:10:00 +0200
> > > From: Marc Wilhelm Küster <marc <at> budabe.eu>
> > > Cc: Marc Wilhelm Küster <marc <at> budabe.eu>,
> > > 	31547 <at> debbugs.gnu.org
> > > 
> > > > That's because your Emacs binary is stripped of debugging symbols.  Is
> > > > there perhaps an auxiliary distribution with those symbols as separate
> > > > files?  If so, could you please install that and repeat what you've
> > > > done?
> > > > 
> > > Not to my knowledge out of the box, I'm afraid. I could perhaps configure and compile my own version of the emacs package with debuging included, but I'd need some time to study how that might work under Archlinux.
> > 
> > If you do decide to build your own Emacs, I suggest to build version
> > 26.1, because it's quite possible this problem is fixed there (and if
> > it isn't, it becomes much more urgent).
> > 
> > > Are there alternatives?
> > 
> > Not that I know of.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Marc Wilhelm Küster <marc <at> budabe.eu>
Cc: 31547 <at> debbugs.gnu.org
Subject: Re: bug#31547: 25.3;
 Core dump: g_main_context_prepare() called recursively from within
 a	source's check() or prepare() member.
Date: Sat, 02 Jun 2018 19:39:40 +0300

> Date: Sat, 02 Jun 2018 18:25:39 +0200
> From: Marc Wilhelm Küster <marc <at> budabe.eu>
> Cc: 31547 <at> debbugs.gnu.org
> 
> in order to get a more meaningful backtrace I've compiled emacs 26.1 directly from its source (source directly downloaded from http://mirror.switch.ch/ftp/mirror/gnu/emacs/emacs-26.1.tar.xz)
> 
> The crash remains fully reproducible. I attach you the backtraces. Of yourse, I'm at your disposal for any additional information you may need

Thanks.

If the crash is reproducible, can you give a step by step recipe,
starting from "emacs -Q", for reproducing it?

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

From: Marc Wilhelm Küster <marc <at> budabe.eu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31547 <at> debbugs.gnu.org
Subject: Re: bug#31547: 25.3; Core dump: g_main_context_prepare() called
 recursively from within a source's check() or prepare() member.
Date: Sat, 2 Jun 2018 19:05:29 +0200

On 06/02/2018 06:39 PM, Eli Zaretskii wrote:

>> Date: Sat, 02 Jun 2018 18:25:39 +0200
>> From: Marc Wilhelm Küster <marc <at> budabe.eu>
>> Cc: 31547 <at> debbugs.gnu.org
>>
>> in order to get a more meaningful backtrace I've compiled emacs 26.1 directly from its source (source directly downloaded from http://mirror.switch.ch/ftp/mirror/gnu/emacs/emacs-26.1.tar.xz)
>>
>> The crash remains fully reproducible. I attach you the backtraces. Of yourse, I'm at your disposal for any additional information you may need
> Thanks.
>
> If the crash is reproducible, can you give a step by step recipe,
> starting from "emacs -Q", for reproducing it?
the first part is

emacs -Q

package-install-packages

Install package "wanderlust" (version 20180506.128)

Start wanderlust (meta x wl)

No comes the problem - given the error message (cf. below) I assume that 
the crash is triggered by trying to display the concrete content of my 
Sent folder (though it is triggered systematically once I open it)

How could we proceed on this?

Best regards,

Marc

...

font_open_entity at /tmp/emacs-26.1/src/font.c:2903
fontset_find_font at /tmp/emacs-26.1/src/fontset.c:709
fontset_font at /tmp/emacs-26.1/src/fontset.c:788
XTYPE at /tmp/emacs-26.1/src/lisp.h:615

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Marc Wilhelm Küster <marc <at> budabe.eu>
Cc: 31547 <at> debbugs.gnu.org
Subject: Re: bug#31547: 25.3; Core dump: g_main_context_prepare() called
 recursively from within a source's check() or prepare() member.
Date: Sat, 02 Jun 2018 22:23:48 +0300

> Cc: 31547 <at> debbugs.gnu.org
> From: Marc Wilhelm Küster <marc <at> budabe.eu>
> Date: Sat, 2 Jun 2018 19:05:29 +0200
> 
> > If the crash is reproducible, can you give a step by step recipe,
> > starting from "emacs -Q", for reproducing it?
> the first part is
> 
> emacs -Q
> 
> package-install-packages
> 
> Install package "wanderlust" (version 20180506.128)
> 
> Start wanderlust (meta x wl)
> 
> No comes the problem - given the error message (cf. below) I assume that 
> the crash is triggered by trying to display the concrete content of my 
> Sent folder (though it is triggered systematically once I open it)
> 
> How could we proceed on this?

I suggest to run Emacs under GDB in X synchronous mode, and then
examining the X error that brings it down.  The file etc/DEBUG
explains how to run Emacs in X synchronous mode, search for "If you
encounter X protocol errors".  We need to know the exact X protocol
request that caused the error, and also the backtrace from there.  The
GDB command "bt" will show the backtrace.

Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Marc Wilhelm Küster <marc <at> budabe.eu>, Robert Pluim
 <rpluim <at> gmail.com>
Cc: 31547 <at> debbugs.gnu.org
Subject: Re: bug#31547: 25.3; Core dump: g_main_context_prepare() called
 recursively from within a source's check() or prepare() member.
Date: Mon, 04 Jun 2018 19:22:31 +0300

[Please keep the bug address on the CC list.]

> From: Marc Wilhelm Küster <marc <at> budabe.eu>
> Date: Sun, 3 Jun 2018 22:40:00 +0200
> 
> When running the error case in gdb the behaviour changes in that it is 
> now possible to open the Sent folder without crash. However, scrolling 
> through the folder's contents causes Emacs to freeze (not crash) 
> reliably. When then interrupting the process in gdb and running a 
> backtrace, I get the following one (I've run this test a couple of times 
> with the same behaviour and substantially the same backtrace each time.
> 
> A possible "culprit" could be a mail with a mix of Latin and Greek 
> characters, but this is just a suspicion (I get a regularly mails with 
> both Latin and Greek characters which don't pose any problems)
> 
> Best regards,
> 
> Marc
> 
> (gdb) run -xrm "emacs.synchronous: true"
> Starting program: /home/mwkuster/src/emacs-26.1/src/emacs -xrm 
> "emacs.synchronous: true"
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/usr/lib/libthread_db.so.1".
> [New Thread 0x7fffe7174700 (LWP 25375)]
> [New Thread 0x7fffe6506700 (LWP 25377)]
> [New Thread 0x7fffe4a51700 (LWP 25380)]
>     **** Emacs freezes while scrolling through the Folder *****
> ^C
> Thread 1 "emacs" received signal SIGINT, Interrupt.
> 0x00007ffff0cc2ffc in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /usr/lib/libpthread.so.0
> (gdb) bt
> #0  0x00007ffff0cc2ffc in pthread_cond_wait@@GLIBC_2.3.2 () at 
> /usr/lib/libpthread.so.0
> #1  0x00007ffff468049d in _XReply () at /usr/lib/libX11.so.6
> #2  0x00007ffff467bfdd in XSync () at /usr/lib/libX11.so.6
> #3  0x00007ffff467c07b in  () at /usr/lib/libX11.so.6
> #4  0x00007ffff3dfaea8 in XftDrawDestroy () at /usr/lib/libXft.so.2
> #5  0x0000000000704769 in xftfont_end_for_frame (f=0x1483c30 
> <bss_sbrk_buffer+6598096>)
>      at xftfont.c:686
> #6  0x000000000067cd57 in font_update_drivers (f=0x1483c30 
> <bss_sbrk_buffer+6598096>, new_drivers=...) at font.c:3540
> #7  0x000000000042fba7 in delete_frame (frame=..., force=...) at 
> frame.c:2006
> #8  0x0000000000557223 in x_connection_closed (dpy=0x2ec1590, 
> error_message=0x7ffffffefd80 "X protocol error: BadLength (poly request 
> too large or internal Xlib length error) on protocol request 139", 
> ioerror=false) at xterm.c:9795
> #9  0x00000000005574a5 in x_error_quitter (display=0x2ec1590, 
> event=0x7ffffffeff30)
>      at xterm.c:9904
> #10 0x00000000005573f0 in x_error_handler (display=0x2ec1590, 
> event=0x7ffffffeff30)
>      at xterm.c:9874
> #11 0x00007ffff46826ed in _XError () at /usr/lib/libX11.so.6
> #12 0x00007ffff467f617 in  () at /usr/lib/libX11.so.6
> #13 0x00007ffff467f6d5 in  () at /usr/lib/libX11.so.6
> #14 0x00007ffff46805e8 in _XReply () at /usr/lib/libX11.so.6
> #15 0x00007ffff467bfdd in XSync () at /usr/lib/libX11.so.6
> #16 0x00007ffff467c07b in  () at /usr/lib/libX11.so.6
> #17 0x00007ffff400b136 in XRenderAddGlyphs () at /usr/lib/libXrender.so.1
> #18 0x00007ffff3dff9e2 in XftFontLoadGlyphs () at /usr/lib/libXft.so.2
> #19 0x00007ffff3dfc5b3 in XftGlyphExtents () at /usr/lib/libXft.so.2
> #20 0x00007ffff3dfc64a in XftTextExtents8 () at /usr/lib/libXft.so.2
> #21 0x0000000000703865 in xftfont_open (f=0x1483c30 
> <bss_sbrk_buffer+6598096>, entity=..., pixel_size=16) at xftfont.c:378

This sounds like another case of bug#30045 and bug#30874.  In both
cases, there's a font that causes libXft to blow up.  If that's the
same bug, it should be solved on the master branch, see the commit
mentioned in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30874#114.

Robert, how about backporting it to the emacs-26 branch, so that it
ends up in Emacs 26.2?

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Marc Wilhelm Küster <marc <at> budabe.eu>
Cc: 31547 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#31547: 25.3;
 Core dump: g_main_context_prepare() called recursively from within a
 source's check() or prepare() member.
Date: Mon, 04 Jun 2018 19:36:52 +0200

[Message part 1 (text/plain, inline)]

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

> [Please keep the bug address on the CC list.]
>
>> From: Marc Wilhelm Küster <marc <at> budabe.eu>
>> Date: Sun, 3 Jun 2018 22:40:00 +0200
>> 
>> When running the error case in gdb the behaviour changes in that it is 
>> now possible to open the Sent folder without crash. However, scrolling 
>> through the folder's contents causes Emacs to freeze (not crash) 
>> reliably. When then interrupting the process in gdb and running a 
>> backtrace, I get the following one (I've run this test a couple of times 
>> with the same behaviour and substantially the same backtrace each time.
>> 
>> A possible "culprit" could be a mail with a mix of Latin and Greek 
>> characters, but this is just a suspicion (I get a regularly mails with 
>> both Latin and Greek characters which don't pose any problems)
>> 
>> Best regards,
>> 
>> Marc
>> 
>> (gdb) run -xrm "emacs.synchronous: true"
>> Starting program: /home/mwkuster/src/emacs-26.1/src/emacs -xrm 
>> "emacs.synchronous: true"
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/usr/lib/libthread_db.so.1".
>> [New Thread 0x7fffe7174700 (LWP 25375)]
>> [New Thread 0x7fffe6506700 (LWP 25377)]
>> [New Thread 0x7fffe4a51700 (LWP 25380)]
>>     **** Emacs freezes while scrolling through the Folder *****
>> ^C
>> Thread 1 "emacs" received signal SIGINT, Interrupt.
>> 0x00007ffff0cc2ffc in pthread_cond_wait@@GLIBC_2.3.2 () from 
>> /usr/lib/libpthread.so.0
>> (gdb) bt
>> #0  0x00007ffff0cc2ffc in pthread_cond_wait@@GLIBC_2.3.2 () at 
>> /usr/lib/libpthread.so.0
>> #1  0x00007ffff468049d in _XReply () at /usr/lib/libX11.so.6
>> #2  0x00007ffff467bfdd in XSync () at /usr/lib/libX11.so.6
>> #3  0x00007ffff467c07b in  () at /usr/lib/libX11.so.6
>> #4  0x00007ffff3dfaea8 in XftDrawDestroy () at /usr/lib/libXft.so.2
>> #5  0x0000000000704769 in xftfont_end_for_frame (f=0x1483c30 
>> <bss_sbrk_buffer+6598096>)
>>      at xftfont.c:686
>> #6  0x000000000067cd57 in font_update_drivers (f=0x1483c30 
>> <bss_sbrk_buffer+6598096>, new_drivers=...) at font.c:3540
>> #7  0x000000000042fba7 in delete_frame (frame=..., force=...) at 
>> frame.c:2006
>> #8  0x0000000000557223 in x_connection_closed (dpy=0x2ec1590, 
>> error_message=0x7ffffffefd80 "X protocol error: BadLength (poly request 
>> too large or internal Xlib length error) on protocol request 139", 
>> ioerror=false) at xterm.c:9795
>> #9  0x00000000005574a5 in x_error_quitter (display=0x2ec1590, 
>> event=0x7ffffffeff30)
>>      at xterm.c:9904
>> #10 0x00000000005573f0 in x_error_handler (display=0x2ec1590, 
>> event=0x7ffffffeff30)
>>      at xterm.c:9874
>> #11 0x00007ffff46826ed in _XError () at /usr/lib/libX11.so.6
>> #12 0x00007ffff467f617 in  () at /usr/lib/libX11.so.6
>> #13 0x00007ffff467f6d5 in  () at /usr/lib/libX11.so.6
>> #14 0x00007ffff46805e8 in _XReply () at /usr/lib/libX11.so.6
>> #15 0x00007ffff467bfdd in XSync () at /usr/lib/libX11.so.6
>> #16 0x00007ffff467c07b in  () at /usr/lib/libX11.so.6
>> #17 0x00007ffff400b136 in XRenderAddGlyphs () at /usr/lib/libXrender.so.1
>> #18 0x00007ffff3dff9e2 in XftFontLoadGlyphs () at /usr/lib/libXft.so.2
>> #19 0x00007ffff3dfc5b3 in XftGlyphExtents () at /usr/lib/libXft.so.2
>> #20 0x00007ffff3dfc64a in XftTextExtents8 () at /usr/lib/libXft.so.2
>> #21 0x0000000000703865 in xftfont_open (f=0x1483c30 
>> <bss_sbrk_buffer+6598096>, entity=..., pixel_size=16) at xftfont.c:378
>
> This sounds like another case of bug#30045 and bug#30874.  In both
> cases, there's a font that causes libXft to blow up.  If that's the
> same bug, it should be solved on the master branch, see the commit
> mentioned in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30874#114.
>

Yes. Just as a sanity check, could you do

XFT_DEBUG=16 ./gdb

and then repeat the same commands? That should give us an indication
of which font XFT is trying to open.

> Robert, how about backporting it to the emacs-26 branch, so that it
> ends up in Emacs 26.2?

Sure. Perhaps a PROBLEMS entry as well? Although if itʼs backported
the problem won't arise.

Marc, Iʼve attached the patch here, would it be possible for you to
check if it fixes your problem?

Thanks

Robert

[out.patch (text/x-diff, inline)]

diff --git c/src/font.c i/src/font.c
index e53935a15c..305bb14576 100644
--- c/src/font.c
+++ i/src/font.c
@@ -5476,6 +5476,13 @@ Disabling compaction of font caches might enlarge the Emacs memory
 footprint in sessions that use lots of different fonts.  */);
   inhibit_compacting_font_caches = 0;
 
+  DEFVAR_BOOL ("xft-ignore-color-fonts",
+	       Vxft_ignore_color_fonts,
+	       doc: /*
+Non-nil means don't query fontconfig for color fonts, since they often
+cause Xft crashes.  Only has an effect in Xft builds.  */);
+  Vxft_ignore_color_fonts = 1;
+
 #ifdef HAVE_WINDOW_SYSTEM
 #ifdef HAVE_FREETYPE
   syms_of_ftfont ();
diff --git c/src/ftfont.c i/src/ftfont.c
index c2e093e633..8f048d2983 100644
--- c/src/ftfont.c
+++ i/src/ftfont.c
@@ -764,6 +764,13 @@ ftfont_spec_pattern (Lisp_Object spec, char *otlayout, struct OpenTypeSpec **ots
   if (scalable >= 0
       && ! FcPatternAddBool (pattern, FC_SCALABLE, scalable ? FcTrue : FcFalse))
     goto err;
+#if defined HAVE_XFT && defined FC_COLOR
+  /* We really don't like color fonts, they cause Xft crashes.  See
+     Bug#30874.  */
+  if (Vxft_ignore_color_fonts
+      && ! FcPatternAddBool (pattern, FC_COLOR, FcFalse))
+    goto err;
+#endif
 
   goto finish;
 

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

From: Marc Wilhelm Küster <marc <at> budabe.eu>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 31547 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#31547: 25.3;
 Core dump: g_main_context_prepare() called recursively from within a
 source's check() or prepare() member.
Date: Mon, 04 Jun 2018 21:03:14 +0200

On Mon, 04 Jun 2018 19:36:52 +0200,
Robert Pluim wrote:
> 
> [1  <text/plain; utf-8 (quoted-printable)>]
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > [Please keep the bug address on the CC list.]
> >
> >> From: Marc Wilhelm Küster <marc <at> budabe.eu>
> >> Date: Sun, 3 Jun 2018 22:40:00 +0200
> >> 
> >> When running the error case in gdb the behaviour changes in that it is 
> >> now possible to open the Sent folder without crash. However, scrolling 
> >> through the folder's contents causes Emacs to freeze (not crash) 
> >> reliably. When then interrupting the process in gdb and running a 
> >> backtrace, I get the following one (I've run this test a couple of times 
> >> with the same behaviour and substantially the same backtrace each time.
> >> 
> >> A possible "culprit" could be a mail with a mix of Latin and Greek 
> >> characters, but this is just a suspicion (I get a regularly mails with 
> >> both Latin and Greek characters which don't pose any problems)
> >> 
> >> Best regards,
> >> 
> >> Marc
> >> 
> >> (gdb) run -xrm "emacs.synchronous: true"
> >> Starting program: /home/mwkuster/src/emacs-26.1/src/emacs -xrm 
> >> "emacs.synchronous: true"
> >> [Thread debugging using libthread_db enabled]
> >> Using host libthread_db library "/usr/lib/libthread_db.so.1".
> >> [New Thread 0x7fffe7174700 (LWP 25375)]
> >> [New Thread 0x7fffe6506700 (LWP 25377)]
> >> [New Thread 0x7fffe4a51700 (LWP 25380)]
> >>     **** Emacs freezes while scrolling through the Folder *****
> >> ^C
> >> Thread 1 "emacs" received signal SIGINT, Interrupt.
> >> 0x00007ffff0cc2ffc in pthread_cond_wait@@GLIBC_2.3.2 () from 
> >> /usr/lib/libpthread.so.0
> >> (gdb) bt
> >> #0  0x00007ffff0cc2ffc in pthread_cond_wait@@GLIBC_2.3.2 () at 
> >> /usr/lib/libpthread.so.0
> >> #1  0x00007ffff468049d in _XReply () at /usr/lib/libX11.so.6
> >> #2  0x00007ffff467bfdd in XSync () at /usr/lib/libX11.so.6
> >> #3  0x00007ffff467c07b in  () at /usr/lib/libX11.so.6
> >> #4  0x00007ffff3dfaea8 in XftDrawDestroy () at /usr/lib/libXft.so.2
> >> #5  0x0000000000704769 in xftfont_end_for_frame (f=0x1483c30 
> >> <bss_sbrk_buffer+6598096>)
> >>      at xftfont.c:686
> >> #6  0x000000000067cd57 in font_update_drivers (f=0x1483c30 
> >> <bss_sbrk_buffer+6598096>, new_drivers=...) at font.c:3540
> >> #7  0x000000000042fba7 in delete_frame (frame=..., force=...) at 
> >> frame.c:2006
> >> #8  0x0000000000557223 in x_connection_closed (dpy=0x2ec1590, 
> >> error_message=0x7ffffffefd80 "X protocol error: BadLength (poly request 
> >> too large or internal Xlib length error) on protocol request 139", 
> >> ioerror=false) at xterm.c:9795
> >> #9  0x00000000005574a5 in x_error_quitter (display=0x2ec1590, 
> >> event=0x7ffffffeff30)
> >>      at xterm.c:9904
> >> #10 0x00000000005573f0 in x_error_handler (display=0x2ec1590, 
> >> event=0x7ffffffeff30)
> >>      at xterm.c:9874
> >> #11 0x00007ffff46826ed in _XError () at /usr/lib/libX11.so.6
> >> #12 0x00007ffff467f617 in  () at /usr/lib/libX11.so.6
> >> #13 0x00007ffff467f6d5 in  () at /usr/lib/libX11.so.6
> >> #14 0x00007ffff46805e8 in _XReply () at /usr/lib/libX11.so.6
> >> #15 0x00007ffff467bfdd in XSync () at /usr/lib/libX11.so.6
> >> #16 0x00007ffff467c07b in  () at /usr/lib/libX11.so.6
> >> #17 0x00007ffff400b136 in XRenderAddGlyphs () at /usr/lib/libXrender.so.1
> >> #18 0x00007ffff3dff9e2 in XftFontLoadGlyphs () at /usr/lib/libXft.so.2
> >> #19 0x00007ffff3dfc5b3 in XftGlyphExtents () at /usr/lib/libXft.so.2
> >> #20 0x00007ffff3dfc64a in XftTextExtents8 () at /usr/lib/libXft.so.2
> >> #21 0x0000000000703865 in xftfont_open (f=0x1483c30 
> >> <bss_sbrk_buffer+6598096>, entity=..., pixel_size=16) at xftfont.c:378
> >
> > This sounds like another case of bug#30045 and bug#30874.  In both
> > cases, there's a font that causes libXft to blow up.  If that's the
> > same bug, it should be solved on the master branch, see the commit
> > mentioned in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30874#114.
> >
> 
> Yes. Just as a sanity check, could you do
> 
> XFT_DEBUG=16 ./gdb
> 
> and then repeat the same commands? That should give us an indication
> of which font XFT is trying to open.

Dear Robert, Eli,

thanks a lot for your help! You're certainly right on your interpretation. Here is the stacktrace:

XFT_DEBUG=16 gdb ./emacs
GNU gdb (GDB) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./emacs...done.
warning: File "/home/mwkuster/src/emacs-26.1/src/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
	add-auto-load-safe-path /home/mwkuster/src/emacs-26.1/src/.gdbinit
line to your configuration file "/home/mwkuster/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/home/mwkuster/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"
(gdb) run -xrm "emacs.synchronous: true"
Starting program: /home/mwkuster/src/emacs-26.1/src/emacs -xrm "emacs.synchronous: true"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffe7174700 (LWP 8933)]
[New Thread 0x7fffe6506700 (LWP 8934)]
XFT_DEBUG=16
[New Thread 0x7fffe4a51700 (LWP 8936)]
FontFile /usr/share/fonts/TTF/DejaVuSansMono.ttf/0 matches new
Loading file /usr/share/fonts/TTF/DejaVuSansMono.ttf/0
FontFile /usr/share/fonts/TTF/DejaVuSansMono-Oblique.ttf/0 matches new
Loading file /usr/share/fonts/TTF/DejaVuSansMono-Oblique.ttf/0
FontFile /usr/share/fonts/TTF/DejaVuSansMono.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/DejaVuSansMono-Bold.ttf/0 matches new
Loading file /usr/share/fonts/TTF/DejaVuSansMono-Bold.ttf/0
FontFile /usr/share/fonts/TTF/DejaVuSansMono.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/DejaVuSansMono.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/HanaMinA.ttf/0 matches new
Loading file /usr/share/fonts/TTF/HanaMinA.ttf/0
FontFile /usr/share/fonts/TTF/HanaMinA.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/HanaMinA.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/HanaMinB.ttf/0 matches new
Loading file /usr/share/fonts/TTF/HanaMinB.ttf/0
FontFile /usr/share/fonts/TTF/HanaMinB.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/HanaMinB.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/HanaMinB.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/HanaMinB.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/HanaMinA.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/HanaMinB.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/HanaMinA.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/DejaVuSansMono.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/DejaVuSansMono.ttf/0 matches existing (3)
FontFile /usr/share/fonts/TTF/DejaVuSans.ttf/0 matches new
Loading file /usr/share/fonts/TTF/DejaVuSans.ttf/0
FontFile /usr/share/fonts/TTF/DejaVuSans-Oblique.ttf/0 matches new
Loading file /usr/share/fonts/TTF/DejaVuSans-Oblique.ttf/0
FontFile /usr/share/fonts/TTF/DejaVuSans.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/DejaVuSansMono-Bold.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/DejaVuSansMono.ttf/0 matches existing (3)
FontFile /usr/share/fonts/TTF/DejaVuSansMono.ttf/0 matches existing (3)
FontFile /usr/share/fonts/TTF/DejaVuSansMono.ttf/0 matches existing (3)
FontFile /usr/share/fonts/noto/NotoColorEmoji.ttf/0 matches new
Loading file /usr/share/fonts/noto/NotoColorEmoji.ttf/0
^C
Thread 1 "emacs" received signal SIGINT, Interrupt.
0x00007ffff0cc2ffc in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
(gdb) bt
#0  0x00007ffff0cc2ffc in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0
#1  0x00007ffff468049d in _XReply () at /usr/lib/libX11.so.6
#2  0x00007ffff467bfdd in XSync () at /usr/lib/libX11.so.6
#3  0x00007ffff467c07b in  () at /usr/lib/libX11.so.6
#4  0x00007ffff3dfaea8 in XftDrawDestroy () at /usr/lib/libXft.so.2
#5  0x0000000000704769 in xftfont_end_for_frame (f=0x1483c30 <bss_sbrk_buffer+6598096>)
    at xftfont.c:686
#6  0x000000000067cd57 in font_update_drivers (f=0x1483c30 <bss_sbrk_buffer+6598096>, new_drivers=...) at font.c:3540
#7  0x000000000042fba7 in delete_frame (frame=..., force=...) at frame.c:2006
#8  0x0000000000557223 in x_connection_closed (dpy=0x2ec1590, error_message=0x7ffffffed1c0 "X protocol error: BadLength (poly request too large or internal Xlib length error) on protocol request 139", ioerror=false) at xterm.c:9795
#9  0x00000000005574a5 in x_error_quitter (display=0x2ec1590, event=0x7ffffffed370)
    at xterm.c:9904
#10 0x00000000005573f0 in x_error_handler (display=0x2ec1590, event=0x7ffffffed370)
    at xterm.c:9874
#11 0x00007ffff46826ed in _XError () at /usr/lib/libX11.so.6
#12 0x00007ffff467f617 in  () at /usr/lib/libX11.so.6
#13 0x00007ffff467f6d5 in  () at /usr/lib/libX11.so.6
#14 0x00007ffff46805e8 in _XReply () at /usr/lib/libX11.so.6
#15 0x00007ffff467bfdd in XSync () at /usr/lib/libX11.so.6
#16 0x00007ffff467c07b in  () at /usr/lib/libX11.so.6
#17 0x00007ffff400b136 in XRenderAddGlyphs () at /usr/lib/libXrender.so.1
#18 0x00007ffff3dff9e2 in XftFontLoadGlyphs () at /usr/lib/libXft.so.2
#19 0x00007ffff3dfc5b3 in XftGlyphExtents () at /usr/lib/libXft.so.2
#20 0x00007ffff3dfc64a in XftTextExtents8 () at /usr/lib/libXft.so.2
#21 0x0000000000703865 in xftfont_open (f=0x1483c30 <bss_sbrk_buffer+6598096>, entity=..., pixel_size=16) at xftfont.c:378
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) q
A debugging session is active.

	Inferior 1 [process 8929] will be killed.

Quit anyway? (y or n) y
[1]+  Done                    emacs  (wd: ~)


In addition, /usr/share/fonts/noto/NotoColorEmoji.ttf/0 is really a font I installed only a couple of months ago, though I make that connection only now

> 
> > Robert, how about backporting it to the emacs-26 branch, so that it
> > ends up in Emacs 26.2?
> 
> Sure. Perhaps a PROBLEMS entry as well? Although if itʼs backported
> the problem won't arise.
> 
> Marc, Iʼve attached the patch here, would it be possible for you to
> check if it fixes your problem?

Robert, I've just applied your patch - and the problem doesn't occur any more!

Thanks to both of you for your great help!

Best regards,

Marc

> 
> Thanks
> 
> Robert
> 
> [2 out.patch <text/x-diff (7bit)>]
> diff --git c/src/font.c i/src/font.c
> index e53935a15c..305bb14576 100644
> --- c/src/font.c
> +++ i/src/font.c
> @@ -5476,6 +5476,13 @@ Disabling compaction of font caches might enlarge the Emacs memory
>  footprint in sessions that use lots of different fonts.  */);
>    inhibit_compacting_font_caches = 0;
>  
> +  DEFVAR_BOOL ("xft-ignore-color-fonts",
> +	       Vxft_ignore_color_fonts,
> +	       doc: /*
> +Non-nil means don't query fontconfig for color fonts, since they often
> +cause Xft crashes.  Only has an effect in Xft builds.  */);
> +  Vxft_ignore_color_fonts = 1;
> +
>  #ifdef HAVE_WINDOW_SYSTEM
>  #ifdef HAVE_FREETYPE
>    syms_of_ftfont ();
> diff --git c/src/ftfont.c i/src/ftfont.c
> index c2e093e633..8f048d2983 100644
> --- c/src/ftfont.c
> +++ i/src/ftfont.c
> @@ -764,6 +764,13 @@ ftfont_spec_pattern (Lisp_Object spec, char *otlayout, struct OpenTypeSpec **ots
>    if (scalable >= 0
>        && ! FcPatternAddBool (pattern, FC_SCALABLE, scalable ? FcTrue : FcFalse))
>      goto err;
> +#if defined HAVE_XFT && defined FC_COLOR
> +  /* We really don't like color fonts, they cause Xft crashes.  See
> +     Bug#30874.  */
> +  if (Vxft_ignore_color_fonts
> +      && ! FcPatternAddBool (pattern, FC_COLOR, FcFalse))
> +    goto err;
> +#endif
>  
>    goto finish;
>  

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 31547 <at> debbugs.gnu.org, marc <at> budabe.eu
Subject: Re: bug#31547: 25.3;
 Core dump: g_main_context_prepare() called recursively from within a
 source's check() or prepare() member.
Date: Mon, 04 Jun 2018 22:14:10 +0300

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 31547 <at> debbugs.gnu.org
> Date: Mon, 04 Jun 2018 19:36:52 +0200
> 
> > Robert, how about backporting it to the emacs-26 branch, so that it
> > ends up in Emacs 26.2?
> 
> Sure. Perhaps a PROBLEMS entry as well? Although if itʼs backported
> the problem won't arise.

Right.  I think you should cherry-pick that commit now.

And this bug should be merged with the other two and closed.

Thanks.

Message #52 received at 31547-done <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: marc <at> budabe.eu, 31547-done <at> debbugs.gnu.org
Subject: Re: bug#31547: 25.3;
 Core dump: g_main_context_prepare() called recursively from within a
 source's check() or prepare() member.
Date: Tue, 05 Jun 2018 14:56:43 +0200

forcemerge 30874 30045 31547
tag 30874 + fixed
quit

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

>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 31547 <at> debbugs.gnu.org
>> Date: Mon, 04 Jun 2018 19:36:52 +0200
>> 
>> > Robert, how about backporting it to the emacs-26 branch, so that it
>> > ends up in Emacs 26.2?
>> 
>> Sure. Perhaps a PROBLEMS entry as well? Although if itʼs backported
>> the problem won't arise.
>
> Right.  I think you should cherry-pick that commit now.
>
> And this bug should be merged with the other two and closed.

I hope Iʼve managed the right debbugs incantation for that.

Marc, thanks for your help with this.

Cherry-pick of 408bf21a8c, 95b77b0451, and 3deaac1bd9 to emacs-26 Pushed as acaebed014

Robert

Previous Next

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