bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Christophe Troestler]

I am using mu4e <https://github.com/djcb/mu/> to read my mail and a spam 
mail with a very long subject line seems to trigger a bug in Emacs.  You 
can see the details (including a backtrace) at 
https://github.com/djcb/mu/issues/880




In GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2016-04-08 on binet, modified by Debian
Windowing system distributor `The X.Org Foundation', version 
11.0.11804000
System Description:	Debian GNU/Linux testing (stretch)

Configured using:
 `configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
 --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
 --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'
Important settings:
  value of $LC_MESSAGES: en_US.UTF-8
  value of $LC_MONETARY: en_GB.UTF-8
  value of $LC_NUMERIC: en_GB.UTF-8
  value of $LC_TIME: en_GB.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Tuareg

Minor modes in effect:
  diff-auto-refine-mode: t
  shell-dirtrack-mode: t
  flyspell-mode: t
  TeX-PDF-mode: t
  merlin-mode: t
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  desktop-save-mode: t
  show-paren-mode: t
  tooltip-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
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
[mu4e] Retrieving mail...done
[mu4e] Indexing... processed 79000, updated 2
[mu4e] Indexing completed; processed 79666, updated 2, cleaned-up 0
[mu4e] Contacts received: 9878
Making completion list... [6 times]
Please enter a number.
Quit
Making completion list...
2 days, 12 hours, 28 minutes, 51 seconds
Making completion list...

Load-path shadows:
/home/trch/software/mu/mu4e/mu4e-meta hides 
/usr/share/emacs24/site-lisp/mu4e/mu4e-meta
/home/trch/software/mu/mu4e/mu4e-vars hides 
/usr/share/emacs24/site-lisp/mu4e/mu4e-vars
/home/trch/software/mu/mu4e/mu4e-message hides 
/usr/share/emacs24/site-lisp/mu4e/mu4e-message
/home/trch/software/mu/mu4e/mu4e-actions hides 
/usr/share/emacs24/site-lisp/mu4e/mu4e-actions
/home/trch/software/mu/mu4e/mu4e-compose hides 
/usr/share/emacs24/site-lisp/mu4e/mu4e-compose
/home/trch/software/mu/mu4e/mu4e-utils hides 
/usr/share/emacs24/site-lisp/mu4e/mu4e-utils
/home/trch/software/mu/mu4e/mu4e-mark hides 
/usr/share/emacs24/site-lisp/mu4e/mu4e-mark
/home/trch/software/mu/mu4e/mu4e-headers hides 
/usr/share/emacs24/site-lisp/mu4e/mu4e-headers
/home/trch/software/mu/mu4e/mu4e-contrib hides 
/usr/share/emacs24/site-lisp/mu4e/mu4e-contrib
/home/trch/software/mu/mu4e/mu4e-lists hides 
/usr/share/emacs24/site-lisp/mu4e/mu4e-lists
/home/trch/software/mu/mu4e/mu4e-main hides 
/usr/share/emacs24/site-lisp/mu4e/mu4e-main
/home/trch/software/mu/mu4e/mu4e-proc hides 
/usr/share/emacs24/site-lisp/mu4e/mu4e-proc
/home/trch/software/mu/mu4e/mu4e-context hides 
/usr/share/emacs24/site-lisp/mu4e/mu4e-context
/home/trch/software/mu/mu4e/mu4e hides 
/usr/share/emacs24/site-lisp/mu4e/mu4e
/home/trch/software/mu/mu4e/mu4e-view hides 
/usr/share/emacs24/site-lisp/mu4e/mu4e-view
/home/trch/software/mu/mu4e/mu4e-draft hides 
/usr/share/emacs24/site-lisp/mu4e/mu4e-draft
/home/trch/software/mu/mu4e/org-mu4e hides 
/usr/share/emacs24/site-lisp/mu4e/org-mu4e
/home/trch/software/mu/mu4e/mu4e-speedbar hides 
/usr/share/emacs24/site-lisp/mu4e/mu4e-speedbar
/home/trch/software/mu/mu4e/org-old-mu4e hides 
/usr/share/emacs24/site-lisp/mu4e/org-old-mu4e
/home/trch/.emacs.d/elpa/ntlm-2.0.0/ntlm hides 
/usr/share/emacs24/site-lisp/flim/ntlm
/usr/share/emacs/24.5/site-lisp/debian-startup hides 
/usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs24/site-lisp/flim/hex-util hides 
/usr/share/emacs/24.5/lisp/hex-util
/usr/share/emacs24/site-lisp/flim/md4 hides 
/usr/share/emacs/24.5/lisp/md4
/usr/share/emacs24/site-lisp/flim/hmac-md5 hides 
/usr/share/emacs/24.5/lisp/net/hmac-md5
/home/trch/.emacs.d/elpa/ntlm-2.0.0/ntlm hides 
/usr/share/emacs/24.5/lisp/net/ntlm
/home/trch/.emacs.d/elpa/soap-client-3.1.1/soap-client hides 
/usr/share/emacs/24.5/lisp/net/soap-client
/usr/share/emacs24/site-lisp/flim/sasl hides 
/usr/share/emacs/24.5/lisp/net/sasl
/usr/share/emacs24/site-lisp/flim/sasl-cram hides 
/usr/share/emacs/24.5/lisp/net/sasl-cram
/home/trch/.emacs.d/elpa/soap-client-3.1.1/soap-inspect hides 
/usr/share/emacs/24.5/lisp/net/soap-inspect
/usr/share/emacs24/site-lisp/flim/sasl-ntlm hides 
/usr/share/emacs/24.5/lisp/net/sasl-ntlm
/usr/share/emacs24/site-lisp/flim/hmac-def hides 
/usr/share/emacs/24.5/lisp/net/hmac-def
/usr/share/emacs24/site-lisp/flim/sasl-digest hides 
/usr/share/emacs/24.5/lisp/net/sasl-digest
/usr/share/emacs24/site-lisp/auctex/context hides 
/usr/share/emacs/site-lisp/auctex/context
/usr/share/emacs24/site-lisp/auctex/tex-buf hides 
/usr/share/emacs/site-lisp/auctex/tex-buf
/usr/share/emacs24/site-lisp/auctex/tex-info hides 
/usr/share/emacs/site-lisp/auctex/tex-info
/usr/share/emacs24/site-lisp/auctex/tex-mik hides 
/usr/share/emacs/site-lisp/auctex/tex-mik
/usr/share/emacs24/site-lisp/auctex/tex-bar hides 
/usr/share/emacs/site-lisp/auctex/tex-bar
/usr/share/emacs24/site-lisp/auctex/tex-font hides 
/usr/share/emacs/site-lisp/auctex/tex-font
/usr/share/emacs24/site-lisp/auctex/tex-jp hides 
/usr/share/emacs/site-lisp/auctex/tex-jp
/usr/share/emacs24/site-lisp/auctex/tex hides 
/usr/share/emacs/site-lisp/auctex/tex
/usr/share/emacs24/site-lisp/auctex/toolbar-x hides 
/usr/share/emacs/site-lisp/auctex/toolbar-x
/usr/share/emacs24/site-lisp/auctex/plain-tex hides 
/usr/share/emacs/site-lisp/auctex/plain-tex
/usr/share/emacs24/site-lisp/auctex/latex hides 
/usr/share/emacs/site-lisp/auctex/latex
/usr/share/emacs24/site-lisp/auctex/tex-style hides 
/usr/share/emacs/site-lisp/auctex/tex-style
/usr/share/emacs24/site-lisp/auctex/preview hides 
/usr/share/emacs/site-lisp/auctex/preview
/usr/share/emacs24/site-lisp/auctex/context-en hides 
/usr/share/emacs/site-lisp/auctex/context-en
/usr/share/emacs24/site-lisp/auctex/texmathp hides 
/usr/share/emacs/site-lisp/auctex/texmathp
/usr/share/emacs24/site-lisp/auctex/context-nl hides 
/usr/share/emacs/site-lisp/auctex/context-nl
/usr/share/emacs24/site-lisp/auctex/bib-cite hides 
/usr/share/emacs/site-lisp/auctex/bib-cite
/usr/share/emacs24/site-lisp/auctex/multi-prompt hides 
/usr/share/emacs/site-lisp/auctex/multi-prompt
/usr/share/emacs24/site-lisp/auctex/tex-fold hides 
/usr/share/emacs/site-lisp/auctex/tex-fold
/usr/share/emacs24/site-lisp/auctex/font-latex hides 
/usr/share/emacs/site-lisp/auctex/font-latex
/usr/share/emacs24/site-lisp/auctex/prv-emacs hides 
/usr/share/emacs/site-lisp/auctex/prv-emacs

Features:
(shadow emacsbug time debian-bug rect sh-script executable grep view
cal-china lunar solar cal-dst cal-islam holidays hol-loaddefs cal-move
css-mode qp mailalias flow-fill mail-extr sort network-stream starttls
tls tramp-cache tramp tramp-compat tramp-loaddefs diff-mode make-mode
markdown-mode etags trampver url-file url-dired url-cache eww mm-url
gnus gnus-ems nnheader shr dabbrev w3m-form mu4e-w3m conf-mode misearch
multi-isearch diary-lib diary-loaddefs latexenc reftex-auc preview
prv-emacs tex-buf reftex-dcr reftex reftex-vars latex tex-style tex-mode
shell org-element org-rmail org-mhe org-irc org-info org-gnus
org-docview org-bibtex org-bbdb org-w3m sgml-mode vc-git flyspell ispell
mule-util caml tuareg_indent tuareg compile smie caml-help font-latex
tex dbus crm bibtex merlin-compat merlin-cap merlin caml-types
caml-emacs tq log-edit pcvs-util add-log erc-list erc-menu erc-join
erc-ring erc-networks erc-pcomplete erc-track erc-match erc-button
erc-fill erc-stamp erc-netsplit erc-goodies erc erc-backend erc-compat
pp twittering-mode url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util mailcap xml org-mu4e 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
ob-core ob-eval org-compat org-macs org-loaddefs find-func mu-cite alist
std11 pccl pccl-20 advice pcustom poem poem-e20 poem-e20_3 pces pces-e20
pces-20 broken poe pym static apel-ver product mu4e-contrib mu4e desktop
frameset mu4e-speedbar speedbar sb-image ezimage dframe mu4e-main
mu4e-context mu4e-view cal-menu calendar cal-loaddefs thingatpt comint
ansi-color ring mu4e-headers mu4e-compose mu4e-draft mu4e-actions ido
rfc2368 smtpmail sendmail mu4e-mark mu4e-message html2text mu4e-proc
mu4e-utils mu4e-lists mu4e-vars message cl-macs format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev mail-utils gmm-utils mailheader hl-line cl gv
mu4e-meta w3m browse-url doc-view jka-compr dired image-mode timezone
w3m-hist w3m-fb bookmark-w3m w3m-ems wid-edit w3m-ccl ccl w3m-favicon
w3m-image w3m-proc w3m-util epa-file epa derived epg quail help-mode
edmacro kmacro paren server url-auth url-parse auth-source eieio
byte-opt bytecomp byte-compile cl-extra cl-loaddefs cl-lib cconv
eieio-core gnus-util mm-util help-fns mail-prsvr password-cache url-vars
info easymenu package epg-config debian-el debian-el-loaddefs w3m-load
preview-latex tex-site auto-loads time-date tooltip electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer 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 make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 584412 138900)
 (symbols 48 53583 12)
 (miscs 40 1246 1495)
 (strings 32 158999 74865)
 (string-bytes 1 4707806)
 (vectors 16 60689)
 (vector-slots 8 1902678 152456)
 (floats 8 943 292)
 (intervals 56 29894 2696)
 (buffers 960 91)
 (heap 1024 265606 14075))

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Eli Zaretskii]

> From: Christophe Troestler <Christophe.Troestler@umons.ac.be>
> Date: Fri, 29 Jul 2016 12:36:46 +0100
> 
> I am using mu4e <https://github.com/djcb/mu/> to read my mail and a spam 
> mail with a very long subject line seems to trigger a bug in Emacs.  You 
> can see the details (including a backtrace) at 
> https://github.com/djcb/mu/issues/880

Thanks, but I don't think I understand what kind of display corruption
did you see, and I see nothing wrong in the backtrace posted there.

So more details are required to understand what's going on here.

Also, would you mind trying the 25.1 release candidate, to see if the
problem still exists there?

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Christophe Troestler]

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


Eli Zaretskii writes:
>> https://github.com/djcb/mu/issues/880
>
>  Thanks, but I don't think I understand what kind of display 
>  corruption did you see,

The corruption is not with the display but with the presentation of the headers (should be aligned left).  See the attached image.

[-- Attachment #2: Emacs2.png --]
[-- Type: image/png, Size: 191959 bytes --]

[-- Attachment #3: Type: text/plain, Size: 555 bytes --]


> and I see nothing wrong in the backtrace posted there.
>  So more details are required to understand what's going on here.

The problem is that, when moving the point to the headers view and, say, 
pressing C-a, Emacs becomes *unresponsive*, even C-g does not work — I 
have to kill it.

/CC Dirk-Jan C. Binnema, the author of mu4e, who may be able to give 
more details.

>  Also, would you mind trying the 25.1 release candidate, to see if the 
>  problem still exists there?

I compiled Emacs from the Git repository and the problem still exists.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Clément Pit--Claudel]

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

On 2016-07-30 08:38, Christophe Troestler wrote:
>> and I see nothing wrong in the backtrace posted there. So more
>> details are required to understand what's going on here.
> 
> The problem is that, when moving the point to the headers view and,
> say, pressing C-a, Emacs becomes *unresponsive*, even C-g does not
> work — I have to kill it.

Does it respond if you run `pkill -SIGUSR2 emacs` (on GNU/Linux)?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Eli Zaretskii]

> From: Christophe Troestler <Christophe.Troestler@umons.ac.be>
> CC: <24109@debbugs.gnu.org>, <djcb@djcbsoftware.nl>
> Date: Sat, 30 Jul 2016 13:38:53 +0100
> 
> Eli Zaretskii writes:
> >> https://github.com/djcb/mu/issues/880
> >
> >  Thanks, but I don't think I understand what kind of display 
> >  corruption did you see,
> 
> The corruption is not with the display but with the presentation of the headers (should be aligned left).  See the attached image.

I must be blind, because they do seem aligned to the left.  Could you
please point to the header that isn't?

In any case, alignment of the headers is most probably an mu4e issue,
unless you can present an Emacs-only recipe that shows something
similar.

> > and I see nothing wrong in the backtrace posted there.
> >  So more details are required to understand what's going on here.
> 
> The problem is that, when moving the point to the headers view and, say, 
> pressing C-a, Emacs becomes *unresponsive*, even C-g does not work — I 
> have to kill it.

I understand, but the backtrace doesn't show anything unusual.  All I
see is Emacs's display engine merging faces for displaying some buffer
text.

Can you show a Lisp backtrace in this situation?  You should be able
to obtain it by the "xbacktrace" GDB command (you may need to "source
src/.gdbinit" from the Emacs source tree, for that command to be
available).

> >  Also, would you mind trying the 25.1 release candidate, to see if the 
> >  problem still exists there?
> 
> I compiled Emacs from the Git repository and the problem still exists.

Thanks.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[martin rudalics]

 > I must be blind, because they do seem aligned to the left.  Could you
 > please point to the header that isn't?

The subject header?

 > I understand, but the backtrace doesn't show anything unusual.  All I
 > see is Emacs's display engine merging faces for displaying some buffer
 > text.

Maybe I'm silly but

#0  assq_no_quit (key=key@entry=16848, list=51100227) at fns.c:1452
#1  0x00000000004b24ac in lface_from_face_name_no_resolve (f=f@entry=0x1237f90, face_name=face_name@entry=16848, signal_p=signal_p@entry=false) at xfaces.c:1862

sounds fishy to me.

But the alignment issue and the assq_no_quit one seem completely
unrelated to me.

martin

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Eli Zaretskii]

> Date: Sat, 30 Jul 2016 19:01:17 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 24109@debbugs.gnu.org, djcb@djcbsoftware.nl
> 
>  > I must be blind, because they do seem aligned to the left.  Could you
>  > please point to the header that isn't?
> 
> The subject header?

Which subject header?

>  > I understand, but the backtrace doesn't show anything unusual.  All I
>  > see is Emacs's display engine merging faces for displaying some buffer
>  > text.
> 
> Maybe I'm silly but
> 
> #0  assq_no_quit (key=key@entry=16848, list=51100227) at fns.c:1452
> #1  0x00000000004b24ac in lface_from_face_name_no_resolve (f=f@entry=0x1237f90, face_name=face_name@entry=16848, signal_p=signal_p@entry=false) at xfaces.c:1862
> 
> sounds fishy to me.

Please explain why.

> But the alignment issue and the assq_no_quit one seem completely
> unrelated to me.

That's my guess as well.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[martin rudalics]

 >> The subject header?
 >
 > Which subject header?

The "Subject" header is not left aligned with "Re: bug#24109:" but maybe
that's just an indentation issue.

 >> #0  assq_no_quit (key=key@entry=16848, list=51100227) at fns.c:1452
 >> #1  0x00000000004b24ac in lface_from_face_name_no_resolve (f=f@entry=0x1237f90, face_name=face_name@entry=16848, signal_p=signal_p@entry=false) at xfaces.c:1862
 >>
 >> sounds fishy to me.
 >
 > Please explain why.

Because the OP reported that Emacs became unresponsive and C-g didn't
quit.  If someone's able to catch Emacs in assq_no_quit, this sounds
like a potential culprit to me.

martin

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Eli Zaretskii]

> Date: Sat, 30 Jul 2016 19:30:32 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Christophe.Troestler@umons.ac.be, 24109@debbugs.gnu.org, 
>  djcb@djcbsoftware.nl
> 
>  >> The subject header?
>  >
>  > Which subject header?
> 
> The "Subject" header is not left aligned with "Re: bug#24109:" but maybe
> that's just an indentation issue.

In what image? the one posted here or the one in
https://github.com/djcb/mu/issues/880?

>  >> #0  assq_no_quit (key=key@entry=16848, list=51100227) at fns.c:1452
>  >> #1  0x00000000004b24ac in lface_from_face_name_no_resolve (f=f@entry=0x1237f90, face_name=face_name@entry=16848, signal_p=signal_p@entry=false) at xfaces.c:1862
>  >>
>  >> sounds fishy to me.
>  >
>  > Please explain why.
> 
> Because the OP reported that Emacs became unresponsive and C-g didn't
> quit.  If someone's able to catch Emacs in assq_no_quit, this sounds
> like a potential culprit to me.

Or it could be part of an infloop that has nothing to do with
assq_no_quit.

Btw, line 1452 in fns.c is not in assq_no_quit, not in any Emacs 24.x
version (the bug is reported for 24.5).  In 25.1, line 1452 is indeed
inside assq_no_quit, so perhaps the version and/or line numbers are
reported incorrectly.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[John Mastro]

Eli Zaretskii <eliz@gnu.org> wrote:
> Btw, line 1452 in fns.c is not in assq_no_quit, not in any Emacs 24.x
> version (the bug is reported for 24.5).  In 25.1, line 1452 is indeed
> inside assq_no_quit, so perhaps the version and/or line numbers are
> reported incorrectly.

The apparent discrepancy is because the reporter is using 24.5 and
reported the bug against that version, but the author/maintainer of mu4e
reproduced the bug in 25.1 and posted the backtrace.

        John

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Eli Zaretskii]

> From: John Mastro <john.b.mastro@gmail.com>
> Date: Sat, 30 Jul 2016 11:30:12 -0700
> Cc: martin rudalics <rudalics@gmx.at>, 24109@debbugs.gnu.org, djcb@djcbsoftware.nl, 
> 	Christophe.Troestler@umons.ac.be
> 
> Eli Zaretskii <eliz@gnu.org> wrote:
> > Btw, line 1452 in fns.c is not in assq_no_quit, not in any Emacs 24.x
> > version (the bug is reported for 24.5).  In 25.1, line 1452 is indeed
> > inside assq_no_quit, so perhaps the version and/or line numbers are
> > reported incorrectly.
> 
> The apparent discrepancy is because the reporter is using 24.5 and
> reported the bug against that version, but the author/maintainer of mu4e
> reproduced the bug in 25.1 and posted the backtrace.

Thanks.

Assuming this problem can be reproduced at will by the reporters, the
best way forward is to use the technique described in etc/DEBUG for
finding the infinite loop, in the section named "If the symptom of the
bug is that Emacs fails to respond".  But before someone does that, I
suggest to rebuild Emacs without optimizations, as those can easily
lead the investigation astray.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Dirk-Jan C. Binnema]

On Saturday Jul 30 2016, John Mastro wrote:

> Eli Zaretskii <eliz@gnu.org> wrote:
>> Btw, line 1452 in fns.c is not in assq_no_quit, not in any Emacs 24.x
>> version (the bug is reported for 24.5).  In 25.1, line 1452 is indeed
>> inside assq_no_quit, so perhaps the version and/or line numbers are
>> reported incorrectly.
>
> The apparent discrepancy is because the reporter is using 24.5 and
> reported the bug against that version, but the author/maintainer of mu4e
> reproduced the bug in 25.1 and posted the backtrace.

Indeed.

I just tried to reproduce the issue with a freshly compiled emacs from
the emacs-25 branch, to get an 'xbacktrace'. But alas, I cannot
reproduce the issue right now, nor with a slightly older emacs :-/

The special case here was a ~700 character subject-header for some spam
message. The "corruption" in the message is a bit of a misnomer, I think
-- it was just emacs scrolling all the way to the right, thus scrolling
the other messages out of view. Haven't seen that with happening with
emacs-25.

I installed emacs-24.5 as well, and cannot reproduce it there
either. So, hopefully reporter is able to reproduce it and get an
xbacktrace.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Yuri D'Elia]

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

I've also stumbled on this bug when using mu4e.
I've rebuilt the current emacs from git (4961cc3f368d9114c305efe6243987bcfa3fd29b) with:

  '--with-x-toolkit=lucid' 'CFLAGS=-O0 -ggdb3'

I've used lucid as that's the normal tk I use. I managed to hang emacs the same
way I currently do on 24.5 (from debian), by scrolling through a *mu4e-headers*
view. C-g does nothing.

The backtrace is as follows:

#0  forward_to_next_line_start (it=0x7fffffff8960, skipped_p=0x7fffffff74be, bidi_it_prev=0x7fffffff6ba0)
    at xdisp.c:6244
#1  0x0000000000443cfa in reseat_at_next_visible_line_start (it=0x7fffffff8960, on_newline_p=false)
    at xdisp.c:6435
#2  0x000000000047053b in display_line (it=0x7fffffff8960) at xdisp.c:21175
#3  0x0000000000462fb3 in try_window (window=20150677, pos=..., flags=1) at xdisp.c:17290
#4  0x0000000000460334 in redisplay_window (window=20150677, just_this_one_p=true) at xdisp.c:16727
#5  0x0000000000459061 in redisplay_window_1 (window=20150677) at xdisp.c:14476
#6  0x00000000005e47f1 in internal_condition_case_1 (bfun=0x45901f <redisplay_window_1>, arg=20150677, 
    handlers=13786163, hfun=0x458f99 <redisplay_window_error>) at eval.c:1337
#7  0x000000000045849b in redisplay_internal () at xdisp.c:14101
#8  0x0000000000456325 in redisplay () at xdisp.c:13263
#9  0x000000000054f480 in read_char (commandflag=1, map=43265955, prev_event=0, 
    used_mouse_menu=0x7fffffffdbaf, end_time=0x0) at keyboard.c:2482
#10 0x000000000055c63c in read_key_sequence (keybuf=0x7fffffffdd60, bufsize=30, prompt=0, 
    dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, 
    prevent_redisplay=false) at keyboard.c:9094
#11 0x000000000054cb9b in command_loop_1 () at keyboard.c:1370
#12 0x00000000005e4757 in internal_condition_case (bfun=0x54c791 <command_loop_1>, handlers=19104, 
    hfun=0x54bf7e <cmd_error>) at eval.c:1313
#13 0x000000000054c49b in command_loop_2 (ignore=0) at keyboard.c:1112
#14 0x00000000005e4089 in internal_catch (tag=46368, func=0x54c472 <command_loop_2>, arg=0) at eval.c:1079
#15 0x000000000054c43d in command_loop () at keyboard.c:1091
#16 0x000000000054bb63 in recursive_edit_1 () at keyboard.c:697
#17 0x000000000054bcda in Frecursive_edit () at keyboard.c:768
#18 0x0000000000549b5c in main (argc=1, argv=0x7fffffffe208) at emacs.c:1658

Lisp Backtrace:
"redisplay_internal (C function)" (0x0)

Emacs is stuck in try_window calling display_line, where the "it" parameter remains constant.
I'm attaching the output of *it in the email, hoping it might be useful.


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

$4158 = {
  window = 20150677, 
  w = 0x1337990, 
  f = 0x1336980, 
  method = GET_FROM_BUFFER, 
  stop_charpos = 26551, 
  prev_stop = 26550, 
  base_level_stop = 26550, 
  end_charpos = 31953, 
  s = 0x0, 
  string_nchars = 0, 
  redisplay_end_trigger_charpos = 0, 
  multibyte_p = true, 
  header_line_p = true, 
  string_from_display_prop_p = false, 
  string_from_prefix_prop_p = false, 
  from_disp_prop_p = false, 
  ellipsis_p = false, 
  avoid_cursor_p = false, 
  dp = 0x21bbac0, 
  dpvec = 0x0, 
  dpend = 0x0, 
  dpvec_char_len = 0, 
  dpvec_face_id = 0, 
  saved_face_id = 11, 
  ctl_chars = {0 <repeats 16 times>}, 
  start = {
    pos = {
      charpos = 26551, 
      bytepos = 27815
    }, 
    overlay_string_index = -1, 
    string_pos = {
      charpos = -1, 
      bytepos = -1
    }, 
    dpvec_index = -1
  }, 
  current = {
    pos = {
      charpos = 26551, 
      bytepos = 27815
    }, 
    overlay_string_index = -1, 
    string_pos = {
      charpos = -1, 
      bytepos = -1
    }, 
    dpvec_index = -1
  }, 
  n_overlay_strings = 0, 
  overlay_strings_charpos = 26550, 
  overlay_strings = {0 <repeats 16 times>}, 
  string_overlays = {0 <repeats 16 times>}, 
  string = 0, 
  from_overlay = 0, 
  stack = {{
      string = 0, 
      string_nchars = 0, 
      end_charpos = 0, 
      stop_charpos = 0, 
      prev_stop = 0, 
      base_level_stop = 0, 
      cmp_it = {
        stop_pos = 0, 
        id = 0, 
        ch = 0, 
        rule_idx = 0, 
        lookback = 0, 
        nglyphs = 0, 
        reversed_p = false, 
        charpos = 0, 
        nchars = 0, 
        nbytes = 0, 
        from = 0, 
        to = 0, 
        width = 0
      }, 
      face_id = 0, 
      u = {
        image = {
          object = 0, 
          slice = {
            x = 0, 
            y = 0, 
            width = 0, 
            height = 0
          }, 
          image_id = 0
        }, 
        stretch = {
          object = 0
        }, 
        xwidget = {
          object = 0
        }
      }, 
      position = {
        charpos = 0, 
        bytepos = 0
      }, 
      current = {
        pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        overlay_string_index = 0, 
        string_pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        dpvec_index = 0
      }, 
      from_overlay = 0, 
      area = LEFT_MARGIN_AREA, 
      method = GET_FROM_BUFFER, 
      paragraph_embedding = NEUTRAL_DIR, 
      multibyte_p = false, 
      string_from_display_prop_p = false, 
      string_from_prefix_prop_p = false, 
      display_ellipsis_p = false, 
      avoid_cursor_p = false, 
      bidi_p = false, 
      from_disp_prop_p = false, 
      line_wrap = TRUNCATE, 
      voffset = 0, 
      space_width = 0, 
      font_height = 0
    }, {
      string = 0, 
      string_nchars = 0, 
      end_charpos = 0, 
      stop_charpos = 0, 
      prev_stop = 0, 
      base_level_stop = 0, 
      cmp_it = {
        stop_pos = 0, 
        id = 0, 
        ch = 0, 
        rule_idx = 0, 
        lookback = 0, 
        nglyphs = 0, 
        reversed_p = false, 
        charpos = 0, 
        nchars = 0, 
        nbytes = 0, 
        from = 0, 
        to = 0, 
        width = 0
      }, 
      face_id = 0, 
      u = {
        image = {
          object = 0, 
          slice = {
            x = 0, 
            y = 0, 
            width = 0, 
            height = 0
          }, 
          image_id = 0
        }, 
        stretch = {
          object = 0
        }, 
        xwidget = {
          object = 0
        }
      }, 
      position = {
        charpos = 0, 
        bytepos = 0
      }, 
      current = {
        pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        overlay_string_index = 0, 
        string_pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        dpvec_index = 0
      }, 
      from_overlay = 0, 
      area = LEFT_MARGIN_AREA, 
      method = GET_FROM_BUFFER, 
      paragraph_embedding = NEUTRAL_DIR, 
      multibyte_p = false, 
      string_from_display_prop_p = false, 
      string_from_prefix_prop_p = false, 
      display_ellipsis_p = false, 
      avoid_cursor_p = false, 
      bidi_p = false, 
      from_disp_prop_p = false, 
      line_wrap = TRUNCATE, 
      voffset = 0, 
      space_width = 0, 
      font_height = 0
    }, {
      string = 0, 
      string_nchars = 0, 
      end_charpos = 0, 
      stop_charpos = 0, 
      prev_stop = 0, 
      base_level_stop = 0, 
      cmp_it = {
        stop_pos = 0, 
        id = 0, 
        ch = 0, 
        rule_idx = 0, 
        lookback = 0, 
        nglyphs = 0, 
        reversed_p = false, 
        charpos = 0, 
        nchars = 0, 
        nbytes = 0, 
        from = 0, 
        to = 0, 
        width = 0
      }, 
      face_id = 0, 
      u = {
        image = {
          object = 0, 
          slice = {
            x = 0, 
            y = 0, 
            width = 0, 
            height = 0
          }, 
          image_id = 0
        }, 
        stretch = {
          object = 0
        }, 
        xwidget = {
          object = 0
        }
      }, 
      position = {
        charpos = 0, 
        bytepos = 0
      }, 
      current = {
        pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        overlay_string_index = 0, 
        string_pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        dpvec_index = 0
      }, 
      from_overlay = 0, 
      area = LEFT_MARGIN_AREA, 
      method = GET_FROM_BUFFER, 
      paragraph_embedding = NEUTRAL_DIR, 
      multibyte_p = false, 
      string_from_display_prop_p = false, 
      string_from_prefix_prop_p = false, 
      display_ellipsis_p = false, 
      avoid_cursor_p = false, 
      bidi_p = false, 
      from_disp_prop_p = false, 
      line_wrap = TRUNCATE, 
      voffset = 0, 
      space_width = 0, 
      font_height = 0
    }, {
      string = 0, 
      string_nchars = 0, 
      end_charpos = 0, 
      stop_charpos = 0, 
      prev_stop = 0, 
      base_level_stop = 0, 
      cmp_it = {
        stop_pos = 0, 
        id = 0, 
        ch = 0, 
        rule_idx = 0, 
        lookback = 0, 
        nglyphs = 0, 
        reversed_p = false, 
        charpos = 0, 
        nchars = 0, 
        nbytes = 0, 
        from = 0, 
        to = 0, 
        width = 0
      }, 
      face_id = 0, 
      u = {
        image = {
          object = 0, 
          slice = {
            x = 0, 
            y = 0, 
            width = 0, 
            height = 0
          }, 
          image_id = 0
        }, 
        stretch = {
          object = 0
        }, 
        xwidget = {
          object = 0
        }
      }, 
      position = {
        charpos = 0, 
        bytepos = 0
      }, 
      current = {
        pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        overlay_string_index = 0, 
        string_pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        dpvec_index = 0
      }, 
      from_overlay = 0, 
      area = LEFT_MARGIN_AREA, 
      method = GET_FROM_BUFFER, 
      paragraph_embedding = NEUTRAL_DIR, 
      multibyte_p = false, 
      string_from_display_prop_p = false, 
      string_from_prefix_prop_p = false, 
      display_ellipsis_p = false, 
      avoid_cursor_p = false, 
      bidi_p = false, 
      from_disp_prop_p = false, 
      line_wrap = TRUNCATE, 
      voffset = 0, 
      space_width = 0, 
      font_height = 0
    }, {
      string = 0, 
      string_nchars = 0, 
      end_charpos = 0, 
      stop_charpos = 0, 
      prev_stop = 0, 
      base_level_stop = 0, 
      cmp_it = {
        stop_pos = 0, 
        id = 0, 
        ch = 0, 
        rule_idx = 0, 
        lookback = 0, 
        nglyphs = 0, 
        reversed_p = false, 
        charpos = 0, 
        nchars = 0, 
        nbytes = 0, 
        from = 0, 
        to = 0, 
        width = 0
      }, 
      face_id = 0, 
      u = {
        image = {
          object = 0, 
          slice = {
            x = 0, 
            y = 0, 
            width = 0, 
            height = 0
          }, 
          image_id = 0
        }, 
        stretch = {
          object = 0
        }, 
        xwidget = {
          object = 0
        }
      }, 
      position = {
        charpos = 0, 
        bytepos = 0
      }, 
      current = {
        pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        overlay_string_index = 0, 
        string_pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        dpvec_index = 0
      }, 
      from_overlay = 0, 
      area = LEFT_MARGIN_AREA, 
      method = GET_FROM_BUFFER, 
      paragraph_embedding = NEUTRAL_DIR, 
      multibyte_p = false, 
      string_from_display_prop_p = false, 
      string_from_prefix_prop_p = false, 
      display_ellipsis_p = false, 
      avoid_cursor_p = false, 
      bidi_p = false, 
      from_disp_prop_p = false, 
      line_wrap = TRUNCATE, 
      voffset = 0, 
      space_width = 0, 
      font_height = 0
    }}, 
  sp = 0, 
  selective = 0, 
  what = IT_CHARACTER, 
  face_id = 0, 
  selective_display_ellipsis_p = true, 
  ctl_arrow_p = true, 
  face_box_p = false, 
  start_of_box_run_p = false, 
  end_of_box_run_p = false, 
  overlay_strings_at_end_processed_p = false, 
  ignore_overlay_strings_at_pos_p = false, 
  glyph_not_available_p = false, 
  starts_in_middle_of_char_p = false, 
  face_before_selective_p = false, 
  constrain_row_ascent_descent_p = false, 
  line_wrap = TRUNCATE, 
  base_face_id = 0, 
  c = 10, 
  len = 1, 
  cmp_it = {
    stop_pos = 26551, 
    id = -1, 
    ch = -2, 
    rule_idx = 0, 
    lookback = 0, 
    nglyphs = 0, 
    reversed_p = false, 
    charpos = 0, 
    nchars = 0, 
    nbytes = 0, 
    from = 0, 
    to = 0, 
    width = 0
  }, 
  char_to_display = 10, 
  glyphless_method = GLYPHLESS_DISPLAY_THIN_SPACE, 
  image_id = 0, 
  xwidget = 0x0, 
  slice = {
    x = 0, 
    y = 0, 
    width = 0, 
    height = 0
  }, 
  space_width = 0, 
  voffset = 0, 
  tab_width = 8, 
  font_height = 0, 
  object = 40630229, 
  position = {
    charpos = 26550, 
    bytepos = 27814
  }, 
  truncation_pixel_width = 9, 
  continuation_pixel_width = 0, 
  first_visible_x = 0, 
  last_visible_x = 946, 
  last_visible_y = 504, 
  extra_line_spacing = 0, 
  max_extra_line_spacing = 0, 
  override_ascent = -1, 
  override_descent = 0, 
  override_boff = 0, 
  glyph_row = 0x2bf8410, 
  area = TEXT_AREA, 
  nglyphs = 1, 
  pixel_width = 9, 
  ascent = 17, 
  descent = 3, 
  max_ascent = 0, 
  max_descent = 0, 
  phys_ascent = 10, 
  phys_descent = 0, 
  max_phys_ascent = 0, 
  max_phys_descent = 0, 
  current_x = 0, 
  continuation_lines_width = 0, 
  eol_pos = {
    charpos = 0, 
    bytepos = 0
  }, 
  current_y = 80, 
  first_vpos = 1, 
  vpos = 3, 
  hpos = 0, 
  left_user_fringe_bitmap = 0, 
  right_user_fringe_bitmap = 0, 
  left_user_fringe_face_id = 0, 
  right_user_fringe_face_id = 0, 
  bidi_p = true, 
  bidi_it = {
    bytepos = 27815, 
    charpos = 26551, 
    ch = 4194302, 
    nchars = 1, 
    ch_len = 2, 
    type = STRONG_L, 
    type_after_wn = STRONG_L, 
    orig_type = STRONG_L, 
    resolved_level = 0 '\000', 
    isolate_level = 0 '\000', 
    invalid_levels = 0, 
    invalid_isolates = 0, 
    prev = {
      charpos = 26550, 
      type = NEUTRAL_B, 
      orig_type = NEUTRAL_B
    }, 
    last_strong = {
      charpos = 26549, 
      type = UNKNOWN_BT, 
      orig_type = UNKNOWN_BT
    }, 
    next_for_neutral = {
      charpos = -1, 
      type = UNKNOWN_BT, 
      orig_type = UNKNOWN_BT
    }, 
    prev_for_neutral = {
      charpos = 26550, 
      type = STRONG_L, 
      orig_type = STRONG_L
    }, 
    next_for_ws = {
      charpos = -1, 
      type = UNKNOWN_BT, 
      orig_type = UNKNOWN_BT
    }, 
    bracket_pairing_pos = -1, 
    bracket_enclosed_type = UNKNOWN_BT, 
    next_en_pos = 0, 
    next_en_type = UNKNOWN_BT, 
    sos = L2R, 
    scan_dir = 1, 
    disp_pos = 26795, 
    disp_prop = 0, 
    stack_idx = 0, 
    level_stack = {{
        next_for_neutral_pos = 0, 
        next_for_neutral_type = 0, 
        last_strong_type = 0, 
        prev_for_neutral_type = 0, 
        level = 0 '\000', 
        flags = 0 '\000'
      } <repeats 128 times>}, 
    string = {
      lstring = 0, 
      s = 0x0, 
      schars = 0, 
      bufpos = 0, 
      from_disp_str = false, 
      unibyte = false
    }, 
    w = 0x1337990, 
    paragraph_dir = L2R, 
    separator_limit = -1, 
    first_elt = false, 
    new_paragraph = false, 
    frame_window_p = true
  }, 
  paragraph_embedding = NEUTRAL_DIR
}

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Yuri D'Elia]

On Tue, Aug 30 2016, Yuri D'Elia <wavexx@thregr.org> wrote:
> Emacs is stuck in try_window calling display_line, where the "it" parameter remains constant.
> I'm attaching the output of *it in the email, hoping it might be useful.

I should also add that if I toggle truncate-lines on the buffer
(toggle-truncate-lines -1), I cannot reproduce the problem.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Eli Zaretskii]

> Date: Tue, 30 Aug 2016 14:38:48 +0200
> From: Yuri D'Elia <wavexx@thregr.org>
> 
> I've also stumbled on this bug when using mu4e.
> I've rebuilt the current emacs from git (4961cc3f368d9114c305efe6243987bcfa3fd29b) with:
> 
>   '--with-x-toolkit=lucid' 'CFLAGS=-O0 -ggdb3'
> 
> I've used lucid as that's the normal tk I use. I managed to hang emacs the same
> way I currently do on 24.5 (from debian), by scrolling through a *mu4e-headers*
> view. C-g does nothing.
> 
> The backtrace is as follows:
> [...]

I see nothing abnormal in the backtrace, at least not at a glance.

> Emacs is stuck in try_window calling display_line, where the "it" parameter remains constant.

What do you mean by "it parameter remains constant"?  That is a large
structure; what parts of it remain constant?

> I'm attaching the output of *it in the email, hoping it might be useful.

Thanks, but it by itself doesn't help enough.  I need to see the text
that Emacs is trying to display, at least.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Yuri D'Elia]

On Tue, Aug 30 2016, Eli Zaretskii <eliz@gnu.org> wrote:
>> The backtrace is as follows:
>> [...]
>
> I see nothing abnormal in the backtrace, at least not at a glance.
>
>> Emacs is stuck in try_window calling display_line, where the "it" parameter remains constant.
>
> What do you mean by "it parameter remains constant"?  That is a large
> structure; what parts of it remain constant?

The address of the structure remains constant (that is, display_line is
called with the same pointer). I don't know if this is expected to
change or not. I didn't actually compare the contents between calls.

>> I'm attaching the output of *it in the email, hoping it might be useful.
>
> Thanks, but it by itself doesn't help enough.  I need to see the text
> that Emacs is trying to display, at least.

This is hard to do. I tried to simply copy the text to another buffer in
trying to reproduce the problem, but I couldn't. It might be due some
overlays or properties.

Is there some way to conveniently dump the entire buffer state to a file
so we can debug this by reloading the content without having the mail
client in the way?

There's a lot of customization in the way which is making this harder
than it should be.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: 24109@debbugs.gnu.org, djcb@djcbsoftware.nl, Christophe.Troestler@umons.ac.be, rudalics@gmx.at
> Date: Tue, 30 Aug 2016 17:51:48 +0200
> 
> >> Emacs is stuck in try_window calling display_line, where the "it" parameter remains constant.
> >
> > What do you mean by "it parameter remains constant"?  That is a large
> > structure; what parts of it remain constant?
> 
> The address of the structure remains constant (that is, display_line is
> called with the same pointer). I don't know if this is expected to
> change or not.

This is expected.  This structure is the object used for iterating
through buffer text in order to prepare its display in a window.  A
single object is used by try_window each time it is called.

What should NOT happen is that the values of it.current.pos stay
constant, or cycle endlessly between the same values.  If you can look
at that, please do.

> Is there some way to conveniently dump the entire buffer state to a file
> so we can debug this by reloading the content without having the mail
> client in the way?

Not that I know of.

I can provide guidance for debugging this, if you can afford it.

Thanks.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Yuri D'Elia]

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

On Tue, Aug 30 2016, Eli Zaretskii <eliz@gnu.org> wrote:
> This is expected.  This structure is the object used for iterating
> through buffer text in order to prepare its display in a window.  A
> single object is used by try_window each time it is called.

Ok

> What should NOT happen is that the values of it.current.pos stay
> constant, or cycle endlessly between the same values.  If you can look
> at that, please do.

I set a breakpoint and dumped the value of it->current.pos.
It seems to cycle every 54 iterations. Attached.


[-- Attachment #2: it-log.txt.gz --]
[-- Type: application/gzip, Size: 2938 bytes --]

[-- Attachment #3: Type: text/plain, Size: 326 bytes --]


>> Is there some way to conveniently dump the entire buffer state to a file
>> so we can debug this by reloading the content without having the mail
>> client in the way?
>
> Not that I know of.

Then, debugging this will be super-annoying :/

> I can provide guidance for debugging this, if you can afford it.

I'm waiting.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: 24109@debbugs.gnu.org, djcb@djcbsoftware.nl, Christophe.Troestler@umons.ac.be, rudalics@gmx.at
> Date: Wed, 31 Aug 2016 11:15:25 +0200
> 
> > What should NOT happen is that the values of it.current.pos stay
> > constant, or cycle endlessly between the same values.  If you can look
> > at that, please do.
> 
> I set a breakpoint and dumped the value of it->current.pos.
> It seems to cycle every 54 iterations. Attached.

Thanks.  Next, we need to establish whether try_window loops in its
loop indefinitely, or its caller calls it in an infinite loop.

The main loop in try_window is this:

  /* Display all lines of W.  */
  while (it.current_y < it.last_visible_y)
    {
      if (display_line (&it))
	last_text_row = it.glyph_row - 1;
      if (f->fonts_changed && !(flags & TRY_WINDOW_IGNORE_FONTS_CHANGE))
	return 0;
    }

Please see if the loop terminates, by setting a breakpoint on the
'return 0' statement and on the line after the loop.

If it terminates, it means try_window does its job correctly, and we
will need to look in the caller, redisplay_window, for the reasons of
this infloop.

> >> Is there some way to conveniently dump the entire buffer state to a file
> >> so we can debug this by reloading the content without having the mail
> >> client in the way?
> >
> > Not that I know of.
> 
> Then, debugging this will be super-annoying :/

Not necessarily, it could be a very simple problem.

Besides, even if there was such a feature, the full state that affects
the display is huge: it should include, in addition to the text
itself, all the text properties, all the face definitions, all the
overlays -- and some of these are dynamically calculated as part of
redisplay.  Even if you could give me that, I'm not sure I could have
spotted the root cause there.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Yuri D'Elia]

On Wed, Aug 31 2016, Eli Zaretskii <eliz@gnu.org> wrote:
> The main loop in try_window is this:
>
>   /* Display all lines of W.  */
>   while (it.current_y < it.last_visible_y)
>     {
>       if (display_line (&it))
>       last_text_row = it.glyph_row - 1;
>       if (f->fonts_changed && !(flags & TRY_WINDOW_IGNORE_FONTS_CHANGE))
>       return 0;
>     }
>
> Please see if the loop terminates, by setting a breakpoint on the
> 'return 0' statement and on the line after the loop.
>
> If it terminates, it means try_window does its job correctly, and we
> will need to look in the caller, redisplay_window, for the reasons of
> this infloop.

It actually terminates.

I've narrowed it down to redisplay_internal(), hitting a goto in
xdisp.c:14144:

    if (hscroll_windows (selected_window))
=>    goto retry;

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: 24109@debbugs.gnu.org, djcb@djcbsoftware.nl, Christophe.Troestler@umons.ac.be, rudalics@gmx.at
> Date: Wed, 31 Aug 2016 17:51:04 +0200
> 
> I've narrowed it down to redisplay_internal(), hitting a goto in
> xdisp.c:14144:
> 
>     if (hscroll_windows (selected_window))
> =>    goto retry;

OK, thanks.  Next question: why does hscroll_windows returns non-zero
when called repeatedly?  It is supposed to do that only once; the next
call should return zero.

For starters, in this line:

	      if (w->hscroll != hscroll)

what are the values of those two, and do they change each time
hscroll_windows is called in the infloop, for the selected window?

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Yuri D'Elia]

On Wed, Aug 31 2016, Eli Zaretskii <eliz@gnu.org> wrote:
> OK, thanks.  Next question: why does hscroll_windows returns non-zero
> when called repeatedly?  It is supposed to do that only once; the next
> call should return zero.
>
> For starters, in this line:
>
>             if (w->hscroll != hscroll)
>
> what are the values of those two, and do they change each time
> hscroll_windows is called in the infloop, for the selected window?

They swap the value at each iteration:

Thread 1 "emacs" hit Breakpoint 14, hscroll_window_tree (window=20142453) at xdisp.c:13086
$154 = 0
$155 = 487
Continuing.

Thread 1 "emacs" hit Breakpoint 14, hscroll_window_tree (window=20142453) at xdisp.c:13086
$156 = 487
$157 = 0
Continuing.

...

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: 24109@debbugs.gnu.org, djcb@djcbsoftware.nl, Christophe.Troestler@umons.ac.be, rudalics@gmx.at
> Date: Wed, 31 Aug 2016 18:49:30 +0200
> 
> > For starters, in this line:
> >
> >             if (w->hscroll != hscroll)
> >
> > what are the values of those two, and do they change each time
> > hscroll_windows is called in the infloop, for the selected window?
> 
> They swap the value at each iteration:
> 
> Thread 1 "emacs" hit Breakpoint 14, hscroll_window_tree (window=20142453) at xdisp.c:13086
> $154 = 0
> $155 = 487
> Continuing.
> 
> Thread 1 "emacs" hit Breakpoint 14, hscroll_window_tree (window=20142453) at xdisp.c:13086
> $156 = 487
> $157 = 0
> Continuing.

What are your values of hscroll-step and hscroll-margin?

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Eli Zaretskii]

> Date: Thu, 01 Sep 2016 05:35:47 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 24109@debbugs.gnu.org, djcb@djcbsoftware.nl,
> 	Christophe.Troestler@umons.ac.be
> 
> > From: Yuri D'Elia <wavexx@thregr.org>
> > Cc: 24109@debbugs.gnu.org, djcb@djcbsoftware.nl, Christophe.Troestler@umons.ac.be, rudalics@gmx.at
> > Date: Wed, 31 Aug 2016 18:49:30 +0200
> > 
> > > For starters, in this line:
> > >
> > >             if (w->hscroll != hscroll)
> > >
> > > what are the values of those two, and do they change each time
> > > hscroll_windows is called in the infloop, for the selected window?
> > 
> > They swap the value at each iteration:
> > 
> > Thread 1 "emacs" hit Breakpoint 14, hscroll_window_tree (window=20142453) at xdisp.c:13086
> > $154 = 0
> > $155 = 487
> > Continuing.
> > 
> > Thread 1 "emacs" hit Breakpoint 14, hscroll_window_tree (window=20142453) at xdisp.c:13086
> > $156 = 487
> > $157 = 0
> > Continuing.
> 
> What are your values of hscroll-step and hscroll-margin?

FWIW, I tried to use your recipe, but failed spectacularly.  mu4e
refuses to run without a working mu installation.  I tried to build mu
on my system, but was forced to give up after 2 hours of fighting with
GMIME and mu itself to compile and work correctly on MS-Windows --
there's too much Posix-only stuff there, and my quick & dirty
workarounds were probably too quick and too dirty.  The best I could
achieve is "mu index --rebuild" cheerfully tell me that it indexed
zero mails, and then (mu4e) in Emacs complained that the database is
empty and refused to continue.

So we are back to me asking questions and you answering them.

In addition to the above, here's one more: when hscroll_window_tree is
called with w->hscroll already non-zero (i.e. after the display engine
scrolls the window to bring point into the view), how come it tries
again to hscroll the window?  The complicated condition that starts at
line 12993 is supposed to yield false in that case, because the X
coordinate of the cursor, stored in w->cursor.x, is now supposed to be
between the left and the right hscroll margins.  Why isn't that
happening in your case?

Some values that might help understand the answer to the above are:

  in C:
    w->cursor
    w->min_hscroll
  in Lisp:
    hscroll-step
    hscroll-margin

Thanks.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Yuri D'Elia]

On Thu, Sep 01 2016, Eli Zaretskii <eliz@gnu.org> wrote:
> FWIW, I tried to use your recipe, but failed spectacularly.  mu4e
> refuses to run without a working mu installation.  I tried to build mu
> on my system, but was forced to give up after 2 hours of fighting with
> GMIME and mu itself to compile and work correctly on MS-Windows --
> there's too much Posix-only stuff there, and my quick & dirty
> workarounds were probably too quick and too dirty.  The best I could
> achieve is "mu index --rebuild" cheerfully tell me that it indexed
> zero mails, and then (mu4e) in Emacs complained that the database is
> empty and refused to continue.

Not too surprising. Cannot help you with windows here, but I could
actually provide a QEMU image preloaded with the test case if you want
(never tried qemu on windows, but I hope there's a way to do it?).

> So we are back to me asking questions and you answering them.

I'll attack this in a few hours.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Yuri D'Elia]

On Thu, Sep 01 2016, Yuri D'Elia <wavexx@thregr.org> wrote:
> Not too surprising. Cannot help you with windows here, but I could
> actually provide a QEMU image preloaded with the test case if you want
> (never tried qemu on windows, but I hope there's a way to do it?).

Huh, qemu-img also supports vdi natively, so this should work directly
on virtualbox.

This would simplify matters a lot. Let me know if you have the ability
to run virtualbox or qemu images.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: 24109@debbugs.gnu.org, djcb@djcbsoftware.nl, Christophe.Troestler@umons.ac.be
> Date: Thu, 01 Sep 2016 16:48:56 +0200
> 
> This would simplify matters a lot. Let me know if you have the ability
> to run virtualbox or qemu images.

I don't even know what that means, so I guess no.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Yuri D'Elia]

On Thu, Sep 01 2016, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Yuri D'Elia <wavexx@thregr.org>
>> Cc: 24109@debbugs.gnu.org, djcb@djcbsoftware.nl, Christophe.Troestler@umons.ac.be
>> Date: Thu, 01 Sep 2016 16:48:56 +0200
>>
>> This would simplify matters a lot. Let me know if you have the ability
>> to run virtualbox or qemu images.
>
> I don't even know what that means, so I guess no.

QEMU (or VirtualBox more generally on windows) emulate a full x86
system.

Basically I would set up a disk image with debian/emacs preloaded with
the test case so you can just run it and test without having to set it
up.

This assumes you're familiar with debugging on linux with gdb though,
otherwise there's no point.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: 24109@debbugs.gnu.org, djcb@djcbsoftware.nl, Christophe.Troestler@umons.ac.be
> Date: Thu, 01 Sep 2016 17:37:46 +0200
> 
> QEMU (or VirtualBox more generally on windows) emulate a full x86
> system.

I don't have it installed.

> Basically I would set up a disk image with debian/emacs preloaded with
> the test case so you can just run it and test without having to set it
> up.

Sounds excessive.  Let's try to debug this some more the "hard" way, I
think we are close.

> This assumes you're familiar with debugging on linux with gdb though,
> otherwise there's no point.

Debugging is not a problem at all.  Installing all of that stuff is.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Eli Zaretskii]

> Date: Thu, 01 Sep 2016 19:00:49 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 24109@debbugs.gnu.org, djcb@djcbsoftware.nl,
> 	Christophe.Troestler@umons.ac.be
> 
> > From: Yuri D'Elia <wavexx@thregr.org>
> > Cc: 24109@debbugs.gnu.org, djcb@djcbsoftware.nl, Christophe.Troestler@umons.ac.be
> > Date: Thu, 01 Sep 2016 17:37:46 +0200
> > 
> > QEMU (or VirtualBox more generally on windows) emulate a full x86
> > system.
> 
> I don't have it installed.
> 
> > Basically I would set up a disk image with debian/emacs preloaded with
> > the test case so you can just run it and test without having to set it
> > up.
> 
> Sounds excessive.  Let's try to debug this some more the "hard" way, I
> think we are close.
> 
> > This assumes you're familiar with debugging on linux with gdb though,
> > otherwise there's no point.
> 
> Debugging is not a problem at all.  Installing all of that stuff is.

Does the problem happen if the recipe is performed in "emacs -nw"?  If
so, I could debug it on a GNU/Linux system to which I have remote
access, or even on yours if you give me a login.

Thanks.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Yuri D'Elia]

On Thu, Jan 01 1970, Yuri D'Elia <wavexx@thregr.org> wrote:
>> What are your values of hscroll-step and hscroll-margin?

hscroll-step 0
hscroll-margin 5

(default values)

> In addition to the above, here's one more: when hscroll_window_tree is
> called with w->hscroll already non-zero (i.e. after the display engine
> scrolls the window to bring point into the view), how come it tries
> again to hscroll the window?  The complicated condition that starts at
> line 12993 is supposed to yield false in that case, because the X
> coordinate of the cursor, stored in w->cursor.x, is now supposed to be
> between the left and the right hscroll margins.  Why isn't that
> happening in your case?
>
> Some values that might help understand the answer to the above are:
>
>   in C:
>     w->cursor
>     w->min_hscroll
>   in Lisp:
>     hscroll-step
>     hscroll-margin

It took me a while to sit down on this issue again.

I noticed one thing while trying to restrict the problem: setting
auto-hscroll-mode to nil, an error is shown in the *Messages* buffer
instead of entering an infinite loop:

previous-line: Beginning of buffer

while not moving the cursor at all on the first invocation, but working
on the second. If something is off there, it might as well be trigger
horizontal scrolling and thus conflict with the current goal column.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: 24109@debbugs.gnu.org, djcb@djcbsoftware.nl, Christophe.Troestler@umons.ac.be
> Date: Sat, 01 Oct 2016 19:10:27 +0200
> 
> On Thu, Jan 01 1970, Yuri D'Elia <wavexx@thregr.org> wrote:
> >> What are your values of hscroll-step and hscroll-margin?
> 
> hscroll-step 0
> hscroll-margin 5
> 
> (default values)
> 
> > In addition to the above, here's one more: when hscroll_window_tree is
> > called with w->hscroll already non-zero (i.e. after the display engine
> > scrolls the window to bring point into the view), how come it tries
> > again to hscroll the window?  The complicated condition that starts at
> > line 12993 is supposed to yield false in that case, because the X
> > coordinate of the cursor, stored in w->cursor.x, is now supposed to be
> > between the left and the right hscroll margins.  Why isn't that
> > happening in your case?
> >
> > Some values that might help understand the answer to the above are:
> >
> >   in C:
> >     w->cursor
> >     w->min_hscroll
> >   in Lisp:
> >     hscroll-step
> >     hscroll-margin
> 
> It took me a while to sit down on this issue again.

Thanks, I hope you will be able to answer the rest of the questions
above, so I could continue looking into this problem.

> I noticed one thing while trying to restrict the problem: setting
> auto-hscroll-mode to nil, an error is shown in the *Messages* buffer
> instead of entering an infinite loop:
> 
> previous-line: Beginning of buffer

Could be related.  previous-line signals this error whenever its
subroutines report that point moved zero lines (more accurately, less
lines than they were asked to move).  It doesn't really check if it
hit BOB.

> while not moving the cursor at all on the first invocation, but working
> on the second. If something is off there, it might as well be trigger
> horizontal scrolling and thus conflict with the current goal column.

Sorry, I don't understand what the last sentence tries to say.

Thanks.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Yuri D'Elia]

[-- Attachment #1: test.el.gz --]
[-- Type: application/gzip, Size: 2739 bytes --]

[-- Attachment #2: 1475346254.png --]
[-- Type: image/png, Size: 52667 bytes --]

[-- Attachment #3: Type: text/plain, Size: 1302 bytes --]

On Sat, Oct 01 2016, Yuri D'Elia <wavexx@thregr.org> wrote:
> I noticed one thing while trying to restrict the problem: setting
> auto-hscroll-mode to nil, an error is shown in the *Messages* buffer
> instead of entering an infinite loop:
>
> previous-line: Beginning of buffer
>
> while not moving the cursor at all on the first invocation, but working
> on the second. If something is off there, it might as well be trigger
> horizontal scrolling and thus conflict with the current goal column.

Ok, after some testing, I was able to get a self-contained test case.
I was successfully able to test this into the current git's master with
emacs -q, built with lucid as the main toolkit.

Please load-file the attached sample. It will create a *test* buffer,
using a quoted representation of (buffer-substring) which is sufficient
to recreate the problem.

It will move the point to the beginning of the last line, as well as
switching on truncate-lines. Having the point on the beginning of the
line is important.

Switch to the *test* buffer and move up. It will hang at the "Luciaine"
line. I'm also attaching a screenshot of my current window state.

If you toggle auto-hscroll-mode instead, before scrolling, you'll see
how the cursor disappears instead when exactly at the beginning of the
line.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: 24109@debbugs.gnu.org, djcb@djcbsoftware.nl, Christophe.Troestler@umons.ac.be
> Date: Sat, 01 Oct 2016 20:25:57 +0200
> 
> Ok, after some testing, I was able to get a self-contained test case.
> I was successfully able to test this into the current git's master with
> emacs -q, built with lucid as the main toolkit.
> 
> Please load-file the attached sample. It will create a *test* buffer,
> using a quoted representation of (buffer-substring) which is sufficient
> to recreate the problem.
> 
> It will move the point to the beginning of the last line, as well as
> switching on truncate-lines. Having the point on the beginning of the
> line is important.
> 
> Switch to the *test* buffer and move up. It will hang at the "Luciaine"
> line. I'm also attaching a screenshot of my current window state.
> 
> If you toggle auto-hscroll-mode instead, before scrolling, you'll see
> how the cursor disappears instead when exactly at the beginning of the
> line.

Thanks, I will look into this soon.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Yuri D'Elia]

On Sun, Oct 02 2016, Eli Zaretskii <eliz@gnu.org> wrote:
> Thanks, I will look into this soon.

Just out of curiosity, can you reproduce the issue at all with the test
case?

I should have some time later today, and I wonder if I should reduce the
test case even further.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: 24109@debbugs.gnu.org, djcb@djcbsoftware.nl, Christophe.Troestler@umons.ac.be
> Date: Tue, 04 Oct 2016 09:16:36 +0200
> 
> On Sun, Oct 02 2016, Eli Zaretskii <eliz@gnu.org> wrote:
> > Thanks, I will look into this soon.
> 
> Just out of curiosity, can you reproduce the issue at all with the test
> case?

Yes, of course.  Otherwise I wouldn't have said I'll look into it.

> I should have some time later today, and I wonder if I should reduce the
> test case even further.

If it's not too much work for you, reducing a test case is always a
good thing.  But it doesn't look too complicated as it is.

Thanks.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Eli Zaretskii]

> Date: Sun, 02 Oct 2016 10:09:53 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 24109@debbugs.gnu.org, djcb@djcbsoftware.nl,
> 	Christophe.Troestler@umons.ac.be
> 
> > From: Yuri D'Elia <wavexx@thregr.org>
> > Cc: 24109@debbugs.gnu.org, djcb@djcbsoftware.nl, Christophe.Troestler@umons.ac.be
> > Date: Sat, 01 Oct 2016 20:25:57 +0200
> > 
> > Ok, after some testing, I was able to get a self-contained test case.
> > I was successfully able to test this into the current git's master with
> > emacs -q, built with lucid as the main toolkit.
> > 
> > Please load-file the attached sample. It will create a *test* buffer,
> > using a quoted representation of (buffer-substring) which is sufficient
> > to recreate the problem.
> > 
> > It will move the point to the beginning of the last line, as well as
> > switching on truncate-lines. Having the point on the beginning of the
> > line is important.
> > 
> > Switch to the *test* buffer and move up. It will hang at the "Luciaine"
> > line. I'm also attaching a screenshot of my current window state.
> > 
> > If you toggle auto-hscroll-mode instead, before scrolling, you'll see
> > how the cursor disappears instead when exactly at the beginning of the
> > line.
> 
> Thanks, I will look into this soon.

Tis is now fixed on the emacs-25 branch.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Yuri D'Elia]

On Sat, Oct 08 2016, Eli Zaretskii <eliz@gnu.org> wrote:
>> > If you toggle auto-hscroll-mode instead, before scrolling, you'll see
>> > how the cursor disappears instead when exactly at the beginning of the
>> > line.
>>
>> Thanks, I will look into this soon.
>
> Tis is now fixed on the emacs-25 branch.

It would be nice to know if this also fixes the original report.

mu4e uses a lot of invisible text in the headers view, but I never
personally had this issue with message-mode.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: 24109-done@debbugs.gnu.org, djcb@djcbsoftware.nl, Christophe.Troestler@umons.ac.be
> Date: Sat, 08 Oct 2016 17:27:49 +0200
> 
> > Tis is now fixed on the emacs-25 branch.
> 
> It would be nice to know if this also fixes the original report.

Someone else will need to check this, I don't use mu4e.  But I don't
expect surprises, as the issue I fixed was quite clear and simple to
fix.

> mu4e uses a lot of invisible text in the headers view

Yes, what I saw in your test file is quite crazy.  Making the
beginning of a line invisible in a buffer that truncates line is about
the worst atrocity one can commit against the display engine.  And
then all those eight-bit bytes (presumably used as markers for
something?) in the invisible part... shudder.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Yuri D'Elia]

On Sat, Oct 08 2016, Eli Zaretskii <eliz@gnu.org> wrote:
>> mu4e uses a lot of invisible text in the headers view
>
> Yes, what I saw in your test file is quite crazy.  Making the
> beginning of a line invisible in a buffer that truncates line is about
> the worst atrocity one can commit against the display engine.  And
> then all those eight-bit bytes (presumably used as markers for
> something?) in the invisible part... shudder.

The headers view is one of the parts of mu4e that I didn't look into
yet. But djcb is in cc :).

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Christophe Troestler]

Yuri D'Elia writes:

>  On Sat, Oct 08 2016, Eli Zaretskii <eliz@gnu.org> wrote:
>> Tis is now fixed on the emacs-25 branch.
>
>  It would be nice to know if this also fixes the original report.

I compiled Emacs 25.1.50.1 from the Git repository (c03d44b) and confirm 
that this version fixes the issue.

bug#24109: 24.5; Long lines in message mode make Emacs irresponsive

[Eli Zaretskii]

> From: Christophe Troestler <Christophe.Troestler@umons.ac.be>
> CC: Eli Zaretskii <eliz@gnu.org>, <24109-done@debbugs.gnu.org>,
> 	<djcb@djcbsoftware.nl>
> Date: Sun, 9 Oct 2016 21:21:51 +0200
> 
> Yuri D'Elia writes:
> 
> >  On Sat, Oct 08 2016, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Tis is now fixed on the emacs-25 branch.
> >
> >  It would be nice to know if this also fixes the original report.
> 
> I compiled Emacs 25.1.50.1 from the Git repository (c03d44b) and confirm 
> that this version fixes the issue.

Great, thanks for testing.