bug#25279: 26.0.50; Slowdown/crash on certain characters

bug#25279: 26.0.50; Slowdown/crash on certain characters

[Richard Copley]

From emacs -Q:
Insert MUSIC FLAT SIGN or RIGHTWARDS DOUBLE ARROW in a buffer.
Move point around in the buffer or edit the buffer text.
Emacs gets very slow, consuming a lot of CPU.
Sometimes it completely grinds to a halt.

MUSIC FLAT SIGN and RIGHTWARDS DOUBLE ARROW are examples
that cause this problem for me. MUSIC SHARP SIGN and
RIGHTWARDS ARROW are examples that do not cause a problem.

Below are the contents of the describe-char buffer for these
characters (with the character itself asterisked out in each
case so as not to crash my Emacs while I edit this mail).

Note the categories. They seem illogical. Are they supposed
to be like that? Why?

Note the fonts. Could there be a bug in "Malgun Gothic"?
As far as I know it's a Korean font installed by default with Windows.
Could there be a bug in "Consolas"? Why does Emacs find the MUSIC
SHARP SIGN glyph but not the MUSIC FLAT SIGN glyph from Consolas?

I asked about this on IRC and there exist Windows Emacs users who
don't have the issue, so it may be influenced by environmental
factors.

Is there anything I can do to avoid it?
Install better fonts? (Any suggestions?)
Uninstall bad fonts?
Configure Emacs to search fonts in a different order?

** RIGHTWARDS DOUBLE ARROW (bad!):

             position: 146 of 148 (98%), column: 0
            character: * (displayed as *) (codepoint 8594, #o20622, #x2192)
    preferred charset: unicode (Unicode (ISO10646))
code point in charset: 0x2192
               script: symbol
               syntax: .     which means: punctuation
             category: .:Base, c:Chinese, h:Korean, j:Japanese
             to input: type "C-x 8 RET 2192" or "C-x 8 RET RIGHTWARDS ARROW"
          buffer code: #xE2 #x86 #x92
            file code: not encodable by coding system iso-latin-1-dos
              display: by this font (glyph code)
    uniscribe:-outline-Consolas-normal-normal-normal-mono-11-*-*-*-c-*-iso8859-1
(#x365)

Character code properties: customize what to show
  name: RIGHTWARDS ARROW
  old-name: RIGHT ARROW
  general-category: Sm (Symbol, Math)
  decomposition: (8594) ('*')

** MUSIC FLAT SIGN (bad!):

             position: 146 of 148 (98%), column: 0
            character: * (displayed as *) (codepoint 9837, #o23155, #x266d)
    preferred charset: unicode (Unicode (ISO10646))
code point in charset: 0x266D
               script: symbol
               syntax: _     which means: symbol
             category: .:Base, h:Korean, j:Japanese
             to input: type "C-x 8 RET 266d" or "C-x 8 RET MUSIC FLAT SIGN"
          buffer code: #xE2 #x99 #xAD
            file code: not encodable by coding system iso-latin-1-dos
              display: by this font (glyph code)
    uniscribe:-outline-Malgun
Gothic-normal-normal-normal-sans-11-*-*-*-p-*-ksc5601.1987-0 (#xCF2)

Character code properties: customize what to show
  name: MUSIC FLAT SIGN
  old-name: FLAT
  general-category: So (Symbol, Other)
  decomposition: (9837) ('*')

** MUSIC SHARP SIGN (ok!):

             position: 148 of 152 (97%), column: 0
            character: * (displayed as *) (codepoint 9839, #o23157, #x266f)
    preferred charset: unicode (Unicode (ISO10646))
code point in charset: 0x266F
               script: symbol
               syntax: _     which means: symbol
             category: .:Base, j:Japanese
             to input: type "C-x 8 RET 266f" or "C-x 8 RET MUSIC SHARP SIGN"
          buffer code: #xE2 #x99 #xAF
            file code: not encodable by coding system iso-latin-1-dos
              display: by this font (glyph code)
    uniscribe:-outline-MS
Gothic-normal-normal-normal-mono-11-*-*-*-c-*-gb2312.1980*-* (#x761)

Character code properties: customize what to show
  name: MUSIC SHARP SIGN
  old-name: SHARP
  general-category: Sm (Symbol, Math)
  decomposition: (9839) ('*')

RIGHTWARDS ARROW (ok!):

             position: 148 of 150 (98%), column: 0
            character: * (displayed as *) (codepoint 8594, #o20622, #x2192)
    preferred charset: unicode (Unicode (ISO10646))
code point in charset: 0x2192
               script: symbol
               syntax: .     which means: punctuation
             category: .:Base, c:Chinese, h:Korean, j:Japanese
             to input: type "C-x 8 RET 2192" or "C-x 8 RET RIGHTWARDS ARROW"
          buffer code: #xE2 #x86 #x92
            file code: not encodable by coding system iso-latin-1-dos
              display: by this font (glyph code)
    uniscribe:-outline-Consolas-normal-normal-normal-mono-11-*-*-*-c-*-iso8859-1
(#x365)

Character code properties: customize what to show
  name: RIGHTWARDS ARROW
  old-name: RIGHT ARROW
  general-category: Sm (Symbol, Math)
  decomposition: (8594) ('*')

In GNU Emacs 26.0.50.10 (x86_64-w64-mingw32)
 of 2016-12-26 built on MACHINE
Repository revision: a8a24b5be7f8cb6741f28000ae34c5b39ad9644e
Windowing system distributor 'Microsoft Corp.', version 10.0.14393
Recent messages:
Making completion list... [3 times]
Quit [2 times]
Mark saved where search started [2 times]
delete-backward-char: Text is read-only
Making completion list... [6 times]
uncompressing eintr.info.gz...done
C-c f is undefined
Making completion list...
Quit [7 times]
nil
Quit
Configured using:
 'configure --prefix=/mingw64 --with-modules --without-imagemagick
 --enable-locallisppath=/site-lisp
 PKG_CONFIG_PATH=/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS MODULES

Important settings:
  value of $LANG: en_GB.UTF-8
  locale-coding-system: cp1252

Major mode: Lisp Interaction

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

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib
dired dired-loaddefs format-spec rfc822 mml mml-sec password-cache epa
derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
jka-compr misearch multi-isearch info easymenu time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript case-table epa-hook jka-cmpr-hook help
simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote w32notify dbusbind w32 multi-tty make-network-process emacs)

Memory information:
((conses 16 105644 8301)
 (symbols 56 20593 0)
 (miscs 48 44 180)
 (strings 32 22316 4034)
 (string-bytes 1 651472)
 (vectors 16 14275)
 (vector-slots 8 449241 5484)
 (floats 8 184 173)
 (intervals 56 414 1299)
 (buffers 976 12))

bug#25279: 26.0.50; Slowdown/crash on certain characters

[Richard Copley]

Two corrections inline below.

On 26 December 2016 at 20:09, Richard Copley <rcopley@gmail.com> wrote:
> From emacs -Q:
> Insert MUSIC FLAT SIGN or RIGHTWARDS DOUBLE ARROW in a buffer.
> Move point around in the buffer or edit the buffer text.
> Emacs gets very slow, consuming a lot of CPU.
> Sometimes it completely grinds to a halt.
>
> MUSIC FLAT SIGN and RIGHTWARDS DOUBLE ARROW are examples
> that cause this problem for me. MUSIC SHARP SIGN and
> RIGHTWARDS ARROW are examples that do not cause a problem.
>
> Below are the contents of the describe-char buffer for these
> characters (with the character itself asterisked out in each
> case so as not to crash my Emacs while I edit this mail).
>
> Note the categories. They seem illogical. Are they supposed
> to be like that? Why?
>
> Note the fonts. Could there be a bug in "Malgun Gothic"?
> As far as I know it's a Korean font installed by default with Windows.
> Could there be a bug in "Consolas"? Why does Emacs find the MUSIC
> SHARP SIGN glyph but not the MUSIC FLAT SIGN glyph from Consolas?

Oops: "Consolas" doesn't have either character. "MS Gothic" has
a glyph for MUSIC SHARP SIGN but not for MUSIC FLAT SIGN.
That goes some way towards explaining why it takes longer to find
a glyph for MUSIC FLAT SIGN. (But I still don't know what to do
about it.)

> I asked about this on IRC and there exist Windows Emacs users who
> don't have the issue, so it may be influenced by environmental
> factors.
>
> Is there anything I can do to avoid it?
> Install better fonts? (Any suggestions?)
> Uninstall bad fonts?
> Configure Emacs to search fonts in a different order?
>

> ** RIGHTWARDS DOUBLE ARROW (bad!):

Oops: I previously gave the describe-char buffer for RIGHTWARDS ARROW.
Here's the text for RIGHTWARDS DOUBLE ARROW:

             position: 148 of 150 (98%), column: 0
            character: * (displayed as *) (codepoint 8658, #o20722, #x21d2)
    preferred charset: unicode (Unicode (ISO10646))
code point in charset: 0x21D2
               script: symbol
               syntax: .     which means: punctuation
             category: .:Base, h:Korean, j:Japanese
             to input: type "C-x 8 RET 21d2" or "C-x 8 RET RIGHTWARDS
DOUBLE ARROW"
          buffer code: #xE2 #x87 #x92
            file code: not encodable by coding system iso-latin-1-dos
              display: by this font (glyph code)
    uniscribe:-outline-Malgun
Gothic-normal-normal-normal-sans-11-*-*-*-p-*-ksc5601.1987-0 (#x22D)

Character code properties: customize what to show
  name: RIGHTWARDS DOUBLE ARROW
  old-name: RIGHT DOUBLE ARROW
  general-category: Sm (Symbol, Math)
  decomposition: (8658) ('*')

> ** MUSIC FLAT SIGN (bad!):
>
>              position: 146 of 148 (98%), column: 0
>             character: * (displayed as *) (codepoint 9837, #o23155, #x266d)
>     preferred charset: unicode (Unicode (ISO10646))
> code point in charset: 0x266D
>                script: symbol
>                syntax: _     which means: symbol
>              category: .:Base, h:Korean, j:Japanese
>              to input: type "C-x 8 RET 266d" or "C-x 8 RET MUSIC FLAT SIGN"
>           buffer code: #xE2 #x99 #xAD
>             file code: not encodable by coding system iso-latin-1-dos
>               display: by this font (glyph code)
>     uniscribe:-outline-Malgun
> Gothic-normal-normal-normal-sans-11-*-*-*-p-*-ksc5601.1987-0 (#xCF2)
>
> Character code properties: customize what to show
>   name: MUSIC FLAT SIGN
>   old-name: FLAT
>   general-category: So (Symbol, Other)
>   decomposition: (9837) ('*')
>
> ** MUSIC SHARP SIGN (ok!):
>
>              position: 148 of 152 (97%), column: 0
>             character: * (displayed as *) (codepoint 9839, #o23157, #x266f)
>     preferred charset: unicode (Unicode (ISO10646))
> code point in charset: 0x266F
>                script: symbol
>                syntax: _     which means: symbol
>              category: .:Base, j:Japanese
>              to input: type "C-x 8 RET 266f" or "C-x 8 RET MUSIC SHARP SIGN"
>           buffer code: #xE2 #x99 #xAF
>             file code: not encodable by coding system iso-latin-1-dos
>               display: by this font (glyph code)
>     uniscribe:-outline-MS
> Gothic-normal-normal-normal-mono-11-*-*-*-c-*-gb2312.1980*-* (#x761)
>
> Character code properties: customize what to show
>   name: MUSIC SHARP SIGN
>   old-name: SHARP
>   general-category: Sm (Symbol, Math)
>   decomposition: (9839) ('*')
>
> RIGHTWARDS ARROW (ok!):
>
>              position: 148 of 150 (98%), column: 0
>             character: * (displayed as *) (codepoint 8594, #o20622, #x2192)
>     preferred charset: unicode (Unicode (ISO10646))
> code point in charset: 0x2192
>                script: symbol
>                syntax: .     which means: punctuation
>              category: .:Base, c:Chinese, h:Korean, j:Japanese
>              to input: type "C-x 8 RET 2192" or "C-x 8 RET RIGHTWARDS ARROW"
>           buffer code: #xE2 #x86 #x92
>             file code: not encodable by coding system iso-latin-1-dos
>               display: by this font (glyph code)
>     uniscribe:-outline-Consolas-normal-normal-normal-mono-11-*-*-*-c-*-iso8859-1
> (#x365)
>
> Character code properties: customize what to show
>   name: RIGHTWARDS ARROW
>   old-name: RIGHT ARROW
>   general-category: Sm (Symbol, Math)
>   decomposition: (8594) ('*')
>
> In GNU Emacs 26.0.50.10 (x86_64-w64-mingw32)
>  of 2016-12-26 built on MACHINE
> Repository revision: a8a24b5be7f8cb6741f28000ae34c5b39ad9644e
> Windowing system distributor 'Microsoft Corp.', version 10.0.14393
> Recent messages:
> Making completion list... [3 times]
> Quit [2 times]
> Mark saved where search started [2 times]
> delete-backward-char: Text is read-only
> Making completion list... [6 times]
> uncompressing eintr.info.gz...done
> C-c f is undefined
> Making completion list...
> Quit [7 times]
> nil
> Quit
> Configured using:
>  'configure --prefix=/mingw64 --with-modules --without-imagemagick
>  --enable-locallisppath=/site-lisp
>  PKG_CONFIG_PATH=/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig'
>
> Configured features:
> XPM JPEG TIFF GIF PNG RSVG SOUND DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB
> TOOLKIT_SCROLL_BARS MODULES
>
> Important settings:
>   value of $LANG: en_GB.UTF-8
>   locale-coding-system: cp1252
>
> Major mode: Lisp Interaction
>
> Minor modes in effect:
>   tooltip-mode: t
>   global-eldoc-mode: t
>   electric-indent-mode: t
>   mouse-wheel-mode: t
>   tool-bar-mode: t
>   menu-bar-mode: t
>   file-name-shadow-mode: t
>   global-font-lock-mode: t
>   font-lock-mode: t
>   blink-cursor-mode: t
>   auto-composition-mode: t
>   auto-encryption-mode: t
>   auto-compression-mode: t
>   line-number-mode: t
>   transient-mark-mode: t
>
> Load-path shadows:
> None found.
>
> Features:
> (shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
> bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib
> dired dired-loaddefs format-spec rfc822 mml mml-sec password-cache epa
> derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode
> mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
> sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
> jka-compr misearch multi-isearch info easymenu time-date mule-util
> tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
> mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars
> term/common-win tool-bar dnd fontset image regexp-opt fringe
> tabulated-list replace newcomment text-mode elisp-mode lisp-mode
> prog-mode register page menu-bar rfn-eshadow isearch timer select
> scroll-bar mouse jit-lock font-lock syntax facemenu font-core
> term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
> vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
> hebrew greek romanian slovak czech european ethiopic indian cyrillic
> chinese composite charscript case-table epa-hook jka-cmpr-hook help
> simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button
> faces cus-face macroexp files text-properties overlay sha1 md5 base64
> format env code-pages mule custom widget hashtable-print-readable
> backquote w32notify dbusbind w32 multi-tty make-network-process emacs)
>
> Memory information:
> ((conses 16 105644 8301)
>  (symbols 56 20593 0)
>  (miscs 48 44 180)
>  (strings 32 22316 4034)
>  (string-bytes 1 651472)
>  (vectors 16 14275)
>  (vector-slots 8 449241 5484)
>  (floats 8 184 173)
>  (intervals 56 414 1299)
>  (buffers 976 12))

bug#25279: 26.0.50; Slowdown/crash on certain characters

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Mon, 26 Dec 2016 20:09:16 +0000
> 
> >From emacs -Q:
> Insert MUSIC FLAT SIGN or RIGHTWARDS DOUBLE ARROW in a buffer.
> Move point around in the buffer or edit the buffer text.
> Emacs gets very slow, consuming a lot of CPU.
> Sometimes it completely grinds to a halt.

Doesn't happen here.

> MUSIC FLAT SIGN and RIGHTWARDS DOUBLE ARROW are examples
> that cause this problem for me. MUSIC SHARP SIGN and
> RIGHTWARDS ARROW are examples that do not cause a problem.
> 
> Below are the contents of the describe-char buffer for these
> characters (with the character itself asterisked out in each
> case so as not to crash my Emacs while I edit this mail).
> 
> Note the categories. They seem illogical. Are they supposed
> to be like that? Why?

Because you don't have Symbola installed, I guess.  The fonts Emacs
finds for displaying these characters all have non-Unicode registry
fields, and that causes Emacs to desperately look for a Unicode font
each time it needs to display one of these characters.

Symbola is referenced in the default fontset with Unicode registry.
You could also customize the fontset with the fonts you have, giving
them iso10646-1 as the registry instead of what you have now, and that
might also fix the problem.  But installing Symbola is better, IMO.

Alternatively, setting inhibit-compacting-font-caches to a non-nil
value will probably work around the problem.

> Note the fonts. Could there be a bug in "Malgun Gothic"?
> As far as I know it's a Korean font installed by default with Windows.
> Could there be a bug in "Consolas"? Why does Emacs find the MUSIC
> SHARP SIGN glyph but not the MUSIC FLAT SIGN glyph from Consolas?

You will need to look into the coverage of these fonts to answer those
questions, I think.  On Windows, Emacs generally examines fonts in the
alphabetical order, looking for the first font that supports the
character, and that's after it tried to use the default face's font.

> I asked about this on IRC and there exist Windows Emacs users who
> don't have the issue, so it may be influenced by environmental
> factors.

Those factors are the fonts they have installed, I think.

bug#25279: 26.0.50; Slowdown/crash on certain characters

[Richard Copley]

On 26 December 2016 at 20:25, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Mon, 26 Dec 2016 20:09:16 +0000
>>
>> >From emacs -Q:
>> Insert MUSIC FLAT SIGN or RIGHTWARDS DOUBLE ARROW in a buffer.
>> Move point around in the buffer or edit the buffer text.
>> Emacs gets very slow, consuming a lot of CPU.
>> Sometimes it completely grinds to a halt.
>
> Doesn't happen here.
>
>> MUSIC FLAT SIGN and RIGHTWARDS DOUBLE ARROW are examples
>> that cause this problem for me. MUSIC SHARP SIGN and
>> RIGHTWARDS ARROW are examples that do not cause a problem.
>>
>> Below are the contents of the describe-char buffer for these
>> characters (with the character itself asterisked out in each
>> case so as not to crash my Emacs while I edit this mail).
>>
>> Note the categories. They seem illogical. Are they supposed
>> to be like that? Why?
>
> Because you don't have Symbola installed, I guess.  The fonts Emacs
> finds for displaying these characters all have non-Unicode registry
> fields, and that causes Emacs to desperately look for a Unicode font
> each time it needs to display one of these characters.

OK, thanks, but I don't quite follow, sorry. Unless you're saying there's a
non-desperate mechanism that's usually used but which fails unless a
font with a Unicode registry field is found for the character?

> Symbola is referenced in the default fontset with Unicode registry.
> You could also customize the fontset with the fonts you have, giving
> them iso10646-1 as the registry instead of what you have now, and that
> might also fix the problem.  But installing Symbola is better, IMO.

Installing Symbola works a treat. Thanks very much.
I wish I could see how to make that information easy to discover.

> Alternatively, setting inhibit-compacting-font-caches to a non-nil
> value will probably work around the problem.
>
>> Note the fonts. Could there be a bug in "Malgun Gothic"?
>> As far as I know it's a Korean font installed by default with Windows.
>> Could there be a bug in "Consolas"? Why does Emacs find the MUSIC
>> SHARP SIGN glyph but not the MUSIC FLAT SIGN glyph from Consolas?
>
> You will need to look into the coverage of these fonts to answer those
> questions, I think.  On Windows, Emacs generally examines fonts in the
> alphabetical order, looking for the first font that supports the
> character, and that's after it tried to use the default face's font.

Commendably thorough, but causes the editor to grind to a halt and crash
in some circumstances.

>> I asked about this on IRC and there exist Windows Emacs users who
>> don't have the issue, so it may be influenced by environmental
>> factors.
>
> Those factors are the fonts they have installed, I think.

Seems so. Thanks again!

bug#25279: 26.0.50; Slowdown/crash on certain characters

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Mon, 26 Dec 2016 20:40:42 +0000
> Cc: 25279@debbugs.gnu.org
> 
> > Because you don't have Symbola installed, I guess.  The fonts Emacs
> > finds for displaying these characters all have non-Unicode registry
> > fields, and that causes Emacs to desperately look for a Unicode font
> > each time it needs to display one of these characters.
> 
> OK, thanks, but I don't quite follow, sorry. Unless you're saying there's a
> non-desperate mechanism that's usually used but which fails unless a
> font with a Unicode registry field is found for the character?

When Emacs doesn't find a font with a Unicode registry, it looks in
many fonts trying many alternative registries.  Each font is tried
twice, ones with the Uniscribe back-end, the other one with the GDI
back-end.  All of that does a lot of consing, so the next GC comes
soon, and compacts font caches by deleting all that information.  Then
the next time redisplay kicks in, it searches all of those fonts
again, and again conses a lot, which again causes GC.  Etc. etc.

> Commendably thorough, but causes the editor to grind to a halt and crash
> in some circumstances.

A crash shouldn't happen in any case, so if you can show a recipe and
a backtrace, maybe this could be fixed.

Thanks.

bug#25279: 26.0.50; Slowdown/crash on certain characters

[Richard Copley]

On 26 December 2016 at 20:49, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Mon, 26 Dec 2016 20:40:42 +0000
>> Cc: 25279@debbugs.gnu.org
>>
>> > Because you don't have Symbola installed, I guess.  The fonts Emacs
>> > finds for displaying these characters all have non-Unicode registry
>> > fields, and that causes Emacs to desperately look for a Unicode font
>> > each time it needs to display one of these characters.
>>
>> OK, thanks, but I don't quite follow, sorry. Unless you're saying there's a
>> non-desperate mechanism that's usually used but which fails unless a
>> font with a Unicode registry field is found for the character?
>
> When Emacs doesn't find a font with a Unicode registry, it looks in
> many fonts trying many alternative registries.  Each font is tried
> twice, ones with the Uniscribe back-end, the other one with the GDI
> back-end.  All of that does a lot of consing, so the next GC comes
> soon, and compacts font caches by deleting all that information.  Then
> the next time redisplay kicks in, it searches all of those fonts
> again, and again conses a lot, which again causes GC.  Etc. etc.
>
>> Commendably thorough, but causes the editor to grind to a halt and crash
>> in some circumstances.
>
> A crash shouldn't happen in any case, so if you can show a recipe and
> a backtrace, maybe this could be fixed.
>
> Thanks.

Reproducing the slowness and high CPU consumption is easy.

The "crash" I referred to is probably better termed a "hang" (as
far as I can see an indefinite one), sorry. I don't know a simple
recipe, but if you use Emacs in this state for long enough, it
usually hangs eventually.

Recipe:
Uninstall Symbola (but perhaps other font changes are required).
Run emacs -Q.

M-x insert-char RET MUSIC SPC FLAT SPC SIGN RET
M-x insert-char RET RIGHTWARDS SPC DOUBLE SPC ARROW RET
C-b ;; place point before the arrow
M-x describe-char RET ;; display a few more arrows

Move point around the scratch buffer and observe that moving
past the FLAT character is slow.
Switch to the describe-char buffer and observe that moving
point past the FLAT character is slow, and scrolling is slow.

Keep doing stuff in that Emacs session until it hangs and stops
responding. This can take some time and might never happen,
but there doesn't seem to be any particular "stuff" that triggers
it. Switching away to a different task for a few minutes and back
again sometimes does it.

Below are C call stacks obtained from a hung emacs process
by attaching gdb to it.

Possibly a clue:
While I had the hung emacs process stopped in GDB I started a
new Emacs process to edit this email and the new Emacs was
also horribly slow! When I killed the process in the debugger,
the new Emacs recovered to normal speed.

(gdb) thread apply all bt full

Thread 6 (Thread 8808.0x304):
#0  0x00007ffc3eb69921 in ntdll!DbgBreakPoint () from
C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#1  0x00007ffc3eb919ba in ntdll!DbgUiRemoteBreakin () from
C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#2  0x00007ffc3c038364 in KERNEL32!BaseThreadInitThunk () from
C:\WINDOWS\System32\kernel32.dll
No symbol table info available.
#3  0x00007ffc3eb270d1 in ntdll!RtlUserThreadStart () from
C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#4  0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 5 (Thread 8808.0x20):
#0  0x00007ffc3eb698a4 in ntdll!ZwWaitForWorkViaWorkerFactory () from
C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#1  0x00007ffc3eaf352e in ntdll!RtlReleaseSRWLockExclusive () from
C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#2  0x00007ffc3c038364 in KERNEL32!BaseThreadInitThunk () from
C:\WINDOWS\System32\kernel32.dll
No symbol table info available.
#3  0x00007ffc3eb270d1 in ntdll!RtlUserThreadStart () from
C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#4  0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 4 (Thread 8808.0xe2c):
#0  0x00007ffc3eb698a4 in ntdll!ZwWaitForWorkViaWorkerFactory () from
C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#1  0x00007ffc3eaf352e in ntdll!RtlReleaseSRWLockExclusive () from
C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#2  0x00007ffc3c038364 in KERNEL32!BaseThreadInitThunk () from
C:\WINDOWS\System32\kernel32.dll
No symbol table info available.
#3  0x00007ffc3eb270d1 in ntdll!RtlUserThreadStart () from
C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#4  0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 3 (Thread 8808.0x2bfc):
#0  0x00007ffc3eb69844 in ntdll!ZwWaitForAlertByThreadId () from
C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#1  0x00007ffc3eaefa87 in ntdll!RtlpUnWaitCriticalSection () from
C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#2  0x00007ffc3eaef98e in ntdll!RtlpUnWaitCriticalSection () from
C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#3  0x00007ffc3eaef81f in ntdll!RtlpUnWaitCriticalSection () from
C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#4  0x00007ffc3eaf0ce4 in ntdll!RtlEnterCriticalSection () from
C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#5  0x00007ffc3eaf0c10 in ntdll!RtlEnterCriticalSection () from
C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#6  0x0000000400216a9b in post_msg ()
No symbol table info available.
#7  0x00000004001f1920 in post_character_message ()
No symbol table info available.
#8  0x00000004001fc2b6 in w32_wnd_proc ()
No symbol table info available.
#9  0x00007ffc3dbe1c24 in USER32!CallWindowProcW () from
C:\WINDOWS\System32\user32.dll
No symbol table info available.
#10 0x00007ffc3dbe156c in USER32!DispatchMessageW () from
C:\WINDOWS\System32\user32.dll
No symbol table info available.
#11 0x00000004001f9dc3 in w32_msg_pump.isra ()
No symbol table info available.
#12 0x00000004001fa430 in w32_msg_worker ()
No symbol table info available.
#13 0x00007ffc3c038364 in KERNEL32!BaseThreadInitThunk () from
C:\WINDOWS\System32\kernel32.dll
No symbol table info available.
#14 0x00007ffc3eb270d1 in ntdll!RtlUserThreadStart () from
C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#15 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 2 (Thread 8808.0x2860):
#0  0x00007ffc3eb66754 in ntdll!ZwDelayExecution () from
C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#1  0x00007ffc3bb6c4a7 in SleepEx () from C:\WINDOWS\System32\KernelBase.dll
No symbol table info available.
#2  0x000000040022fad9 in timer_loop ()
No symbol table info available.
#3  0x00007ffc3c038364 in KERNEL32!BaseThreadInitThunk () from
C:\WINDOWS\System32\kernel32.dll
No symbol table info available.
#4  0x00007ffc3eb270d1 in ntdll!RtlUserThreadStart () from
C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#5  0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 1 (Thread 8808.0x2cf8):
#0  0x00007ffc3c0196a4 in win32u!NtUserSetMenu () from
C:\WINDOWS\System32\win32u.dll
No symbol table info available.
#1  0x00000004002031ad in set_frame_menubar ()
No symbol table info available.
#2  0x00000004000229c0 in update_menu_bar.part ()
No symbol table info available.
#3  0x0000000400051e21 in redisplay_internal ()
No symbol table info available.
#4  0x0000000400054de5 in redisplay_preserve_echo_area ()
No symbol table info available.
#5  0x000000040000cf52 in sit_for ()
No symbol table info available.
#6  0x00000004000f31c9 in command_loop_1 ()
No symbol table info available.
#7  0x0000000400175809 in internal_condition_case ()
No symbol table info available.
#8  0x00000004000e1614 in command_loop_2 ()
No symbol table info available.
#9  0x00000004001756f7 in internal_catch ()
No symbol table info available.
#10 0x00000004000e14f3 in command_loop ()
No symbol table info available.
#11 0x00000004000e8f94 in recursive_edit_1 ()
No symbol table info available.
#12 0x000000040011c221 in read_minibuf ()
No symbol table info available.
#13 0x000000040011cbad in Fread_from_minibuffer ()
No symbol table info available.
#14 0x0000000400177c04 in Ffuncall ()
No symbol table info available.
#15 0x00000004001c3e56 in exec_byte_code ()
No symbol table info available.
#16 0x000000040017747d in funcall_lambda ()
No symbol table info available.
#17 0x00000004001778a1 in Ffuncall ()
No symbol table info available.
#18 0x000000040011ac19 in Fcompleting_read ()
No symbol table info available.
#19 0x0000000400177cf1 in Ffuncall ()
No symbol table info available.
#20 0x00000004001c3e56 in exec_byte_code ()
No symbol table info available.
#21 0x000000040017747d in funcall_lambda ()
No symbol table info available.
#22 0x00000004001778a1 in Ffuncall ()
No symbol table info available.
#23 0x00000004001c3e56 in exec_byte_code ()
No symbol table info available.
#24 0x00000004001c68be in Fbyte_code ()
No symbol table info available.
#25 0x0000000400176b42 in eval_sub ()
No symbol table info available.
#26 0x000000040017c96b in Feval ()
No symbol table info available.
#27 0x0000000400172dca in Fcall_interactively ()
No symbol table info available.
#28 0x0000000400177c89 in Ffuncall ()
No symbol table info available.
#29 0x00000004001c3e56 in exec_byte_code ()
No symbol table info available.
#30 0x000000040017747d in funcall_lambda ()
No symbol table info available.
#31 0x00000004001778a1 in Ffuncall ()
No symbol table info available.
#32 0x0000000400177d8d in call1 ()
No symbol table info available.
#33 0x00000004000f291f in command_loop_1 ()
No symbol table info available.
#34 0x0000000400175809 in internal_condition_case ()
No symbol table info available.
#35 0x00000004000e1614 in command_loop_2 ()
No symbol table info available.
#36 0x00000004001756f7 in internal_catch ()
No symbol table info available.
#37 0x00000004000e15c9 in command_loop ()
No symbol table info available.
#38 0x00000004000e62c4 in Frecursive_edit ()
No symbol table info available.
#39 0x000000040026e699 in main ()
No symbol table info available.

bug#25279: 26.0.50; Slowdown/crash on certain characters

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Mon, 26 Dec 2016 21:21:57 +0000
> Cc: 25279@debbugs.gnu.org
> 
> > A crash shouldn't happen in any case, so if you can show a recipe and
> > a backtrace, maybe this could be fixed.
> >
> > Thanks.
> 
> Reproducing the slowness and high CPU consumption is easy.
> 
> The "crash" I referred to is probably better termed a "hang" (as
> far as I can see an indefinite one), sorry. I don't know a simple
> recipe, but if you use Emacs in this state for long enough, it
> usually hangs eventually.

Is it a hang, or just some long and very busy loop?  E.g., if you set
garbage-collection-messages to a non-nil value, do you see periodic
announcements of GC during the "hang"?  And if you go for a coffee,
does Emacs eventually recover and starts responding again?  What if
you type M-< or M-> to force the problematic characters out of the
displayed portion of the buffer -- does Emacs recover then?

> Recipe:
> Uninstall Symbola (but perhaps other font changes are required).

It isn't easy to uninstall fonts from a running system, because they
are usually in use by some application.  So reproducing this will be
hard for me, as I have Symbola installed everywhere.  I will try to
find such a system, but no promises.

> Below are C call stacks obtained from a hung emacs process
> by attaching gdb to it.

Is it possible for you to try to figure out what is the looping stack
frame, by following the advice in etc/DEBUG, under "If the symptom of
the bug is that Emacs fails to respond"?

> Possibly a clue:
> While I had the hung emacs process stopped in GDB I started a
> new Emacs process to edit this email and the new Emacs was
> also horribly slow! When I killed the process in the debugger,
> the new Emacs recovered to normal speed.

Attaching a debugger to Emacs built from the master branch causes such
problems due to the low-level keyboard hook in Emacs.  (We avoid that
problem when Emacs is started from GDB to begin with.)  So I don't
think this is relevant to the issue at hand.

Thanks.

bug#25279: Fwd: bug#25279: 26.0.50; Slowdown/crash on certain characters

[Richard Copley]

I inadvertently replied to Eli without CC'ing the bug.
Forwarded message for the record:

On 27 December 2016 at 07:21, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Mon, 26 Dec 2016 21:21:57 +0000
>> Cc: 25279@debbugs.gnu.org
>>
>> > A crash shouldn't happen in any case, so if you can show a recipe and
>> > a backtrace, maybe this could be fixed.
>> >
>> > Thanks.
>>
>> Reproducing the slowness and high CPU consumption is easy.
>>
>> The "crash" I referred to is probably better termed a "hang" (as
>> far as I can see an indefinite one), sorry. I don't know a simple
>> recipe, but if you use Emacs in this state for long enough, it
>> usually hangs eventually.
>
> Is it a hang, or just some long and very busy loop?

If it's a long busy loop, it's very very long.

> E.g., if you set
> garbage-collection-messages to a non-nil value, do you see periodic
> announcements of GC during the "hang"?

No! (I was surprised.) Currently the message area says "quit".
(I don't know whether it's always "quit".)

>  And if you go for a coffee,
> does Emacs eventually recover and starts responding again?

I've tried coffee, beer, even a good night's sleep, but all to no effect.

> What if
> you type M-< or M-> to force the problematic characters out of the
> displayed portion of the buffer -- does Emacs recover then?

No apparent effect.

>> Recipe:
>> Uninstall Symbola (but perhaps other font changes are required).
>
> It isn't easy to uninstall fonts from a running system, because they
> are usually in use by some application.  So reproducing this will be
> hard for me, as I have Symbola installed everywhere.  I will try to
> find such a system, but no promises.
>
>> Below are C call stacks obtained from a hung emacs process
>> by attaching gdb to it.
>
> Is it possible for you to try to figure out what is the looping stack
> frame, by following the advice in etc/DEBUG, under "If the symptom of
> the bug is that Emacs fails to respond"?

This is the hanging function / stack frame:

#0  0x00007ffc3c011184 in win32u!NtUserMessageCall () from
C:\WINDOWS\System32\win32u.dll
#1  0x00007ffc3dbe116d in USER32!SendMessageW () from
C:\WINDOWS\System32\user32.dll
#2  0x00007ffc3dbe83e5 in USER32!SendMessageA () from
C:\WINDOWS\System32\user32.dll
#3  0x000000040020cf33 in w32_set_vertical_scroll_bar ()
#4  0x0000000400063938 in redisplay_window ()
#5  0x0000000400067e86 in redisplay_window_0 ()
#6  0x0000000400175951 in internal_condition_case_1 ()
#7  0x0000000400026eea in redisplay_windows ()
#8  0x0000000400051669 in redisplay_internal ()
#9  0x00000004000ed795 in read_char ()
#10 0x00000004000f0790 in read_key_sequence.constprop ()
#11 0x00000004000f26eb in command_loop_1 ()
#12 0x0000000400175809 in internal_condition_case ()
#13 0x00000004000e1614 in command_loop_2 ()
#14 0x00000004001756f7 in internal_catch ()
#15 0x00000004000e15c9 in command_loop ()
#16 0x00000004000e62c4 in Frecursive_edit ()
#17 0x000000040026e699 in main ()

That's with "-O3". There's something up with my environment that's
stopping me from rebuilding Emacs. l'll get back to you when I have
a backtrace with "-Og -g -ggdb".

>> Possibly a clue:
>> While I had the hung emacs process stopped in GDB I started a
>> new Emacs process to edit this email and the new Emacs was
>> also horribly slow! When I killed the process in the debugger,
>> the new Emacs recovered to normal speed.
>
> Attaching a debugger to Emacs built from the master branch causes such
> problems due to the low-level keyboard hook in Emacs.  (We avoid that
> problem when Emacs is started from GDB to begin with.)  So I don't
> think this is relevant to the issue at hand.
>
> Thanks.

bug#25279: Fwd: bug#25279: 26.0.50; Slowdown/crash on certain characters

[Richard Copley]

I inadvertently replied to Eli without CC'ing the bug.
Forwarded message for the record:

On 27 December 2016 at 12:38, Richard Copley <rcopley@gmail.com> wrote:
> That's with "-O3". There's something up with my environment that's
> stopping me from rebuilding Emacs. l'll get back to you when I have
> a backtrace with "-Og -g -ggdb".

By the way, I'm becoming more convinced that typing "C-g" is a
required part of the recipe and is the final trigger. Still less than
50% convinced though.

Here is the backtrace.

#0  0x00007ffc3c011184 in win32u!NtUserMessageCall () from
C:\WINDOWS\System32\win32u.dll
No symbol table info available.
#1  0x00007ffc3dbe116d in USER32!SendMessageW () from
C:\WINDOWS\System32\user32.dll
No symbol table info available.
#2  0x00007ffc3dbe83e5 in USER32!SendMessageA () from
C:\WINDOWS\System32\user32.dll
No symbol table info available.
#3  0x000000040018ed49 in my_show_window (f=f@entry=0x4009456b0
<dumped_data+3536272>, hwnd=hwnd@entry=0xf2069a, how=how@entry=1)
    at ../../repo/emacs/src/w32term.c:3671
No locals.
#4  0x000000040019387a in w32_set_vertical_scroll_bar (w=0x0,
portion=3686, whole=13332, position=0) at
../../repo/emacs/src/w32term.c:3864
        hwnd = 0xf2069a
        bar = <optimized out>
        top = 0
        height = 1001
        left = 1903
        width = 17
        window_y = 0
        window_height = 1001
#5  0x000000040002aba0 in set_vertical_scroll_bar
(w=w@entry=0x4009466c0 <dumped_data+3540384>) at
../../repo/emacs/src/xdisp.c:16149
        start = 0
        end = <optimized out>
        whole = 21
#6  0x000000040004f46c in redisplay_window (window=<optimized out>,
just_this_one_p=just_this_one_p@entry=false) at
../../repo/emacs/src/xdisp.c:17322
        old = <optimized out>
        lpoint = <optimized out>
        opoint = <optimized out>
        startp = {charpos = 17189590709, bytepos = 1}
        update_mode_line = <optimized out>
        tem = <optimized out>
        it = {window = 0, w = 0x0, f = 0x0, method = GET_FROM_BUFFER,
stop_charpos = 0, prev_stop = 0, base_level_stop = 0, end_charpos = 0,
s = 0x0,
          string_nchars = 5, redisplay_end_trigger_charpos = 5,
multibyte_p = true, header_line_p = true, string_from_display_prop_p =
true,
          string_from_prefix_prop_p = true, from_disp_prop_p = true,
ellipsis_p = true, avoid_cursor_p = true, dp = 0xffffffffffffffff,
          dpvec = 0xffffffffffffffff, dpend = 0xffffffff,
dpvec_char_len = 5, dpvec_face_id = 0, saved_face_id = 5, ctl_chars =
{-1, -1, -1, 4294967295,
            0, 5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, start = {pos =
{charpos = 0, bytepos = 0}, overlay_string_index = 0, string_pos =
{charpos = 0,
              bytepos = 0}, dpvec_index = 0}, current = {pos =
{charpos = 0, bytepos = 0}, overlay_string_index = 0, string_pos =
{charpos = 0,
              bytepos = 0}, dpvec_index = 0}, n_overlay_strings = 0,
overlay_strings_charpos = 0, 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 = 5}, face_id = 35, u = {image
= {
                  object = 498216206336, slice = {x = 1, y = 2, width
= -1, height = 4294967294}, image_id = 0}, stretch = {object =
498216206336},
                xwidget = {object = 498216206336}}, position =
{charpos = 0, bytepos = 0}, current = {pos = {charpos = 0, bytepos =
0},
                overlay_string_index = 0, string_pos = {charpos = 116,
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 = 524288}}, sp = 0, selective = 79375365, what = IT_EOB,
face_id = 0,
          selective_display_ellipsis_p = true, ctl_arrow_p = false,
face_box_p = true, 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 = 393216, c = 0, len = 1887, cmp_it = {stop_pos
= 0, id = 4294967295, ch = 0, rule_idx = 0, lookback = 87650496,
nglyphs = 1,
            reversed_p = true, charpos = 42949672966, nchars = 3,
nbytes = 0, from = 0, to = 0, width = 1}, char_to_display = 0,
          glyphless_method = GLYPHLESS_DISPLAY_THIN_SPACE, image_id =
0, xwidget = 0x0, slice = {x = 0, y = 13, width = 1, height = 0},
          space_width = 4294967296, voffset = 5, tab_width = 0,
font_height = 5, object = 4294967295, position = {charpos = 1, bytepos
= 1},
          truncation_pixel_width = 6, continuation_pixel_width = 0,
first_visible_x = 6, last_visible_x = 6, last_visible_y = 0,
extra_line_spacing = 0,
          max_extra_line_spacing = 0, override_ascent = 0,
override_descent = 0, override_boff = 4, glyph_row = 0x100000000, area
= 4, nglyphs = 0,
          pixel_width = 0, ascent = 0, descent = -1, max_ascent = -1,
max_descent = 0, phys_ascent = 0, phys_descent = 5, max_phys_ascent =
0,
          max_phys_descent = 1, current_x = 1,
continuation_lines_width = -1, eol_pos = {charpos = 0, bytepos = -1},
current_y = 0, first_vpos = 0,
          vpos = 0, hpos = 0, left_user_fringe_bitmap = 0,
right_user_fringe_bitmap = 0, left_user_fringe_face_id = 1,
right_user_fringe_face_id = 1,
          bidi_p = false, bidi_it = {bytepos = 5, charpos = 0, ch = 0,
nchars = 0, ch_len = 0, type = UNKNOWN_BT, type_after_wn = UNKNOWN_BT,
            orig_type = UNKNOWN_BT, resolved_level = 0 '\000',
isolate_level = 0 '\000', invalid_levels = 0, invalid_isolates = 0,
prev = {charpos = 0,
              type = UNKNOWN_BT, orig_type = UNKNOWN_BT}, last_strong
= {charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT},
next_for_neutral = {
              charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT},
prev_for_neutral = {charpos = 0, type = UNKNOWN_BT, orig_type =
UNKNOWN_BT},
            next_for_ws = {charpos = 0, type = UNKNOWN_BT, orig_type =
UNKNOWN_BT}, bracket_pairing_pos = 0, bracket_enclosed_type =
UNKNOWN_BT,
            next_en_pos = 0, next_en_type = UNKNOWN_BT, sos =
NEUTRAL_DIR, scan_dir = 0, disp_pos = 0, 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 91 times>,
{next_for_neutral_pos = 0, next_for_neutral_type = 3, last_strong_type
= 2,
                prev_for_neutral_type = 0, level = 16 '\020', flags =
0 '\000'}, {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'}, {next_for_neutral_pos = 0,
                next_for_neutral_type = 5, last_strong_type = 2,
prev_for_neutral_type = 3, level = 16 '\020', flags = 0 '\000'}, {
                next_for_neutral_pos = 85549728, next_for_neutral_type
= 0, last_strong_type = 0, prev_for_neutral_type = 1, level = 93 ']',
                flags = 0 '\000'}, {next_for_neutral_pos = 86822288,
next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type
= 3,
                level = 148 '"', flags = 0 '\000'},
{next_for_neutral_pos = 79375365, next_for_neutral_type = 5,
last_strong_type = 3,
                prev_for_neutral_type = 4, level = 16 '\020', flags =
0 '\000'}, {next_for_neutral_pos = 0, next_for_neutral_type = 1,
                last_strong_type = 6, prev_for_neutral_type = 3, level
= 16 '\020', flags = 0 '\000'}, {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'}, {
                next_for_neutral_pos = 0, next_for_neutral_type = 0,
last_strong_type = 2, prev_for_neutral_type = 2, level = 225 'á',
flags = 3 '\003'},
              {next_for_neutral_pos = 65093264, next_for_neutral_type
= 7, last_strong_type = 4, prev_for_neutral_type = 0, level = 16
'\020',
                flags = 0 '\000'}, {next_for_neutral_pos = 0,
next_for_neutral_type = 5, last_strong_type = 5, prev_for_neutral_type
= 0,
                level = 16 '\020', flags = 0 '\000'},
{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'}, {next_for_neutral_pos = 339000, next_for_neutral_type = 1,
                last_strong_type = 2, prev_for_neutral_type = 1, level
= 16 '\020', flags = 0 '\000'}, {next_for_neutral_pos = 17185818960,
                next_for_neutral_type = 3, last_strong_type = 4,
prev_for_neutral_type = 7, level = 13 '\r', flags = 0 '\000'}, {
                next_for_neutral_pos = 79375360, next_for_neutral_type
= 0, last_strong_type = 6, prev_for_neutral_type = 2, level = 95 '_',
                flags = 0 '\000'}, {next_for_neutral_pos = 79375360,
next_for_neutral_type = 2, last_strong_type = 2, prev_for_neutral_type
= 2,
                level = 12 '\f', flags = 0 '\000'},
{next_for_neutral_pos = 0, next_for_neutral_type = 4, last_strong_type
= 6,
                prev_for_neutral_type = 7, level = 16 '\020', flags =
0 '\000'}, {next_for_neutral_pos = 17186166656, next_for_neutral_type
= 1,
                last_strong_type = 1, prev_for_neutral_type = 1, level
= 13 '\r', flags = 0 '\000'}, {next_for_neutral_pos = 17186114736,
                next_for_neutral_type = 1, last_strong_type = 5,
prev_for_neutral_type = 3, level = 5 '\005', flags = 0 '\000'}, {
                next_for_neutral_pos = 17185902512,
next_for_neutral_type = 0, last_strong_type = 7, prev_for_neutral_type
= 2, level = 92 '\\',
                flags = 0 '\000'}, {next_for_neutral_pos =
17186114736, next_for_neutral_type = 2, last_strong_type = 0,
prev_for_neutral_type = 0,
                level = 48 '0', flags = 0 '\000'},
{next_for_neutral_pos = 2, next_for_neutral_type = 2, last_strong_type
= 1, prev_for_neutral_type = 0,
                level = 16 '\020', flags = 0 '\000'},
{next_for_neutral_pos = 17186166661, next_for_neutral_type = 1,
last_strong_type = 7,
                prev_for_neutral_type = 5, level = 1 '\001', flags = 0
'\000'}, {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'}, {next_for_neutral_pos = 0,
                next_for_neutral_type = 0, last_strong_type = 7,
prev_for_neutral_type = 7, level = 0 '\000', flags = 0 '\000'}, {
                next_for_neutral_pos = 3200002, next_for_neutral_type
= 0, last_strong_type = 7, prev_for_neutral_type = 2, level = 92 '\\',
                flags = 0 '\000'}, {next_for_neutral_pos = 2,
next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type
= 0,
                level = 0 '\000', flags = 0 '\000'},
{next_for_neutral_pos = 1, next_for_neutral_type = 0, last_strong_type
= 6,
                prev_for_neutral_type = 2, level = 148 '"', flags = 0
'\000'}, {next_for_neutral_pos = 0, next_for_neutral_type = 0,
                last_strong_type = 1, prev_for_neutral_type = 0, level
= 16 '\020', flags = 0 '\000'}, {next_for_neutral_pos = 4,
                next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000'}, {
                next_for_neutral_pos = 17189598928,
next_for_neutral_type = 7, last_strong_type = 0, prev_for_neutral_type
= 0, level = 0 '\000',
                flags = 0 '\000'}, {next_for_neutral_pos = 0,
next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type
= 3,
                level = 191 '¿', flags = 0 '\000'},
{next_for_neutral_pos = 2, next_for_neutral_type = 2, last_strong_type
= 0,
                prev_for_neutral_type = 0, level = 48 '0', flags = 0
'\000'}, {next_for_neutral_pos = 17185939640, next_for_neutral_type =
1,
                last_strong_type = 1, prev_for_neutral_type = 4, level
= 17 '\021', flags = 0 '\000'}, {next_for_neutral_pos = 57176,
                next_for_neutral_type = 2, last_strong_type = 5,
prev_for_neutral_type = 1, level = 17 '\021', flags = 0 '\000'}, {
                next_for_neutral_pos = 0, next_for_neutral_type = 7,
last_strong_type = 1, prev_for_neutral_type = 2, level = 1 '\001',
                flags = 0 '\000'}, {next_for_neutral_pos = 84820109,
next_for_neutral_type = 6, last_strong_type = 0, prev_for_neutral_type
= 0,
                level = 0 '\000', flags = 0 '\000'}}, string =
{lstring = 0, s = 0x0, schars = 79375365, bufpos = 17181036314,
from_disp_str = false,
              unibyte = true}, w = 0x40001df95
<with_echo_area_buffer+535>, paragraph_dir = (R2L | unknown: 4),
separator_limit = 17189598928,
            first_elt = true, new_paragraph = false, frame_window_p =
true}, paragraph_embedding = (unknown: 29176)}
        current_matrix_up_to_date_p = <optimized out>
        used_current_matrix_p = <optimized out>
        buffer_unchanged_p = <optimized out>
        temp_scroll_step = false
        rc = <optimized out>
        centering_position = <optimized out>
        last_line_misfit = <optimized out>
        beg_unchanged = <optimized out>
        end_unchanged = <optimized out>
        frame_line_height = <optimized out>
        use_desired_matrix = <optimized out>
        itdata = <optimized out>
#7  0x000000040004fd29 in redisplay_window_0 (window=<optimized out>)
at ../../repo/emacs/src/xdisp.c:14565
No locals.
#8  0x000000040011c816 in internal_condition_case_1
(bfun=bfun@entry=0x40004fcf6 <redisplay_window_0>, arg=17189594821,
handlers=<optimized out>,
    hfun=hfun@entry=0x400013a99 <redisplay_window_error>) at
../../repo/emacs/src/eval.c:1358
        val = 402
        c = <optimized out>
#9  0x000000040001e253 in redisplay_windows (window=17189594821) at
../../repo/emacs/src/xdisp.c:14545
No locals.
#10 0x000000040004082b in redisplay_internal () at
../../repo/emacs/src/xdisp.c:14034
        gcscrollbars = <optimized out>
        f_redisplay_flag = false
        w = <optimized out>
        sw = <optimized out>
        pending = <optimized out>
        must_finish = <optimized out>
        match_p = <optimized out>
        tlbufpos = <optimized out>
        tlendpos = <optimized out>
        number_of_visible_frames = 1
        polling_stopped_here = <optimized out>
        tail = 17190839075
        hscroll_retries = 0
        consider_all_windows_p = <optimized out>
        update_miniwindow_p = <optimized out>
#11 0x0000000400041929 in redisplay () at ../../repo/emacs/src/xdisp.c:13279
No locals.
#12 0x00000004000b80fc in read_char (commandflag=5950960,
map=133143986176, map@entry=126627411, prev_event=0,
used_mouse_menu=0x0,
    used_mouse_menu@entry=0xbff53b, end_time=end_time@entry=0x0) at
../../repo/emacs/src/keyboard.c:2485
        echo_current = false
        c = <optimized out>
        jmpcount = <optimized out>
        local_getcjmp = {{Part = {3950, 36512}}, {Part = {13353,
13333}}, {Part = {1, 1}}, {Part = {0, 0}}, {Part = {0, 86694179}},
{Part = {0, 0}}, {
            Part = {3, 126627443}}, {Part = {57176, 0}}, {Part =
{4294967295, 3}}, {Part = {126627427, 17180658796}}, {Part = {0,
12579832}}, {Part = {
              17186166656, 17180738633}}, {Part = {17186744000,
88144304}}, {Part = {84820109, 17185898528}}, {Part = {0, 0}}, {Part =
{12580720, 0}}}
        save_jump = {{Part = {0, 0}}, {Part = {0, 0}}, {Part = {0,
0}}, {Part = {17186114736, 17181376377}}, {Part = {0, 0}}, {Part = {0,
0}}, {Part = {
              0, 0}}, {Part = {0, 0}}, {Part = {0, 3}}, {Part = {0,
0}}, {Part = {12579168, 40}}, {Part = {0, 17186239056}}, {Part =
{2036544,
              17180968497}}, {Part = {13333, 1}}, {Part = {1,
17186114736}}, {Part = {17187521152, 17180658451}}}
        tem = <optimized out>
        save = <optimized out>
        previous_echo_area_message = 0
        also_record = 0
        reread = false
        recorded = false
        polling_stopped_here = false
        orig_kboard = 0x0
#13 0x00000004000b9862 in read_key_sequence (keybuf=<optimized out>,
keybuf@entry=0xbff630, bufsize=bufsize@entry=30, prompt=<optimized
out>,
    prompt@entry=0, dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true,
    fix_current_buffer=fix_current_buffer@entry=true,
prevent_redisplay=prevent_redisplay@entry=false) at
../../repo/emacs/src/keyboard.c:9139
        interrupted_kboard = 0x3e1eeb0
        key = <optimized out>
        used_mouse_menu = false
        echo_local_start = 0
        last_real_key_start = 0
        keys_local_start = <optimized out>
        new_binding = <optimized out>
        t = 0
        echo_start = 0
        keys_start = 0
        current_binding = 126627411
        first_event = 0
        first_unbound = 31
        mock_input = 0
        fkey = {parent = 17187008595, map = 17187008595, start = 0, end = 0}
        keytran = {parent = 17186092611, map = 17186092611, start = 0, end = 0}
        indec = {parent = 17187008707, map = 17187008707, start = 0, end = 0}
        shift_translated = false
        delayed_switch_frame = 0
        original_uppercase = 0
        original_uppercase_position = -1
        dummyflag = false
        starting_buffer = 0x4005f4cb0 <dumped_data+60304>
        fake_prefixed_keys = 0
#14 0x00000004000bb06b in command_loop_1 () at
../../repo/emacs/src/keyboard.c:1373
        cmd = <optimized out>
        keybuf = {121964243, 98, 0, 3, 218344, 126627539, 17181881508,
0, 0, 17180598227, 0, 17180597119, 5, 35000, 17185898528, 0, 0,
17180598519, 3,
          17187751795, 17185898528, 17181052207, 0, 59472, 12580816,
17181623372, 1, 39806736, 17185898528, 17181034045}
        i = <optimized out>
        prev_modiff = 0
        prev_buffer = 0x0
#15 0x000000040011c7a3 in internal_condition_case
(bfun=bfun@entry=0x4000bae2a <command_loop_1>,
handlers=handlers@entry=23184,
    hfun=hfun@entry=0x4000b2008 <cmd_error>) at ../../repo/emacs/src/eval.c:1334
        val = 402
        c = <optimized out>
#16 0x00000004000ad3e9 in command_loop_2 (ignore=<optimized out>) at
../../repo/emacs/src/keyboard.c:1115
        val = 402
#17 0x000000040011c738 in internal_catch (tag=tag@entry=59472,
func=func@entry=0x4000ad3cd <command_loop_2>, arg=arg@entry=0)
    at ../../repo/emacs/src/eval.c:1100
        val = 402
        c = <optimized out>
#18 0x00000004000ad31c in command_loop () at
../../repo/emacs/src/keyboard.c:1094
No locals.
#19 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

bug#25279: 26.0.50; Slowdown/crash on certain characters

[Richard Copley]

On 27 December 2016 at 13:47, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Tue, 27 Dec 2016 13:36:52 +0000
>>
>> After scrolling up and down with and moving point around like crazy (to
>> try to trigger the bug), Emacs can temporarily stop responding while it
>> catches up (there are, as you deduced, a lot of garbage collections),
>> but doesn't hang for a long time.
>>
>> But pressing C-g can cause the indefinite hang in SendMessage seen
>> above.
>
> How many threads are in the program when the hang happens?

6, according to an earlier message in this bug.

> Is the
> input thread still running?  It should be stuck in w32_msg_pump or
> w32_wnd_proc.

Sounds like Thread 3 from that earlier message.

Thread 3 (Thread 8808.0x2bfc):
#0  0x00007ffc3eb69844 in ntdll!ZwWaitForAlertByThreadId () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x00007ffc3eaefa87 in ntdll!RtlpUnWaitCriticalSection () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x00007ffc3eaef98e in ntdll!RtlpUnWaitCriticalSection () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#3  0x00007ffc3eaef81f in ntdll!RtlpUnWaitCriticalSection () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x00007ffc3eaf0ce4 in ntdll!RtlEnterCriticalSection () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#5  0x00007ffc3eaf0c10 in ntdll!RtlEnterCriticalSection () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x0000000400216a9b in post_msg ()
#7  0x00000004001f1920 in post_character_message ()
#8  0x00000004001fc2b6 in w32_wnd_proc ()
#9  0x00007ffc3dbe1c24 in USER32!CallWindowProcW () from
C:\WINDOWS\System32\user32.dll
#10 0x00007ffc3dbe156c in USER32!DispatchMessageW () from
C:\WINDOWS\System32\user32.dll
#11 0x00000004001f9dc3 in w32_msg_pump.isra ()
#12 0x00000004001fa430 in w32_msg_worker ()
#13 0x00007ffc3c038364 in KERNEL32!BaseThreadInitThunk () from
C:\WINDOWS\System32\kernel32.dll
#14 0x00007ffc3eb270d1 in ntdll!RtlUserThreadStart () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#15 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

> The backtrace you show seems to say that SendMessage doesn't return,
> which might mean the thread it is sending the message to is either
> dead or not responding.  That thread is the input thread.

Maybe a deadly embrace then. I'll research how to ask GDB about the
state of kernel sync objects.
Any tips welcome.

bug#25279: 26.0.50; Slowdown/crash on certain characters

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Tue, 27 Dec 2016 14:06:27 +0000
> Cc: 25279@debbugs.gnu.org
> 
> >> But pressing C-g can cause the indefinite hang in SendMessage seen
> >> above.
> >
> > How many threads are in the program when the hang happens?
> 
> 6, according to an earlier message in this bug.
> 
> > Is the
> > input thread still running?  It should be stuck in w32_msg_pump or
> > w32_wnd_proc.
> 
> Sounds like Thread 3 from that earlier message.
> 
> Thread 3 (Thread 8808.0x2bfc):
> #0  0x00007ffc3eb69844 in ntdll!ZwWaitForAlertByThreadId () from
> C:\WINDOWS\SYSTEM32\ntdll.dll
> #1  0x00007ffc3eaefa87 in ntdll!RtlpUnWaitCriticalSection () from
> C:\WINDOWS\SYSTEM32\ntdll.dll
> #2  0x00007ffc3eaef98e in ntdll!RtlpUnWaitCriticalSection () from
> C:\WINDOWS\SYSTEM32\ntdll.dll
> #3  0x00007ffc3eaef81f in ntdll!RtlpUnWaitCriticalSection () from
> C:\WINDOWS\SYSTEM32\ntdll.dll
> #4  0x00007ffc3eaf0ce4 in ntdll!RtlEnterCriticalSection () from
> C:\WINDOWS\SYSTEM32\ntdll.dll
> #5  0x00007ffc3eaf0c10 in ntdll!RtlEnterCriticalSection () from
> C:\WINDOWS\SYSTEM32\ntdll.dll
> #6  0x0000000400216a9b in post_msg ()
> #7  0x00000004001f1920 in post_character_message ()
> #8  0x00000004001fc2b6 in w32_wnd_proc ()
> #9  0x00007ffc3dbe1c24 in USER32!CallWindowProcW () from
> C:\WINDOWS\System32\user32.dll
> #10 0x00007ffc3dbe156c in USER32!DispatchMessageW () from
> C:\WINDOWS\System32\user32.dll
> #11 0x00000004001f9dc3 in w32_msg_pump.isra ()
> #12 0x00000004001fa430 in w32_msg_worker ()
> #13 0x00007ffc3c038364 in KERNEL32!BaseThreadInitThunk () from
> C:\WINDOWS\System32\kernel32.dll
> #14 0x00007ffc3eb270d1 in ntdll!RtlUserThreadStart () from
> C:\WINDOWS\SYSTEM32\ntdll.dll
> #15 0x0000000000000000 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> > The backtrace you show seems to say that SendMessage doesn't return,
> > which might mean the thread it is sending the message to is either
> > dead or not responding.  That thread is the input thread.
> 
> Maybe a deadly embrace then. I'll research how to ask GDB about the
> state of kernel sync objects.

I think I see what's happening: it's a deadlock.  When you type C-g,
the input thread (which receives all keyboard input from Windows),
sets the quit-flag, then attempts to send the C-g character to the
main thread.  To send the message, it tries to enter critical section,
and waits for it.  Meanwhile, the main thread tries to tell the input
thread to draw the scroll bar, and calls SendMessage for that.
SendMessage waits for the input thread to receive the message, but the
input thread is stuck waiting for the main thread to exit the critical
section.

bug#25279: 26.0.50; Slowdown/crash on certain characters

[Richard Copley]

On 27 December 2016 at 14:15, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Tue, 27 Dec 2016 14:06:27 +0000
>> Cc: 25279@debbugs.gnu.org
>>
>> >> But pressing C-g can cause the indefinite hang in SendMessage seen
>> >> above.
>> >
>> > How many threads are in the program when the hang happens?
>>
>> 6, according to an earlier message in this bug.
>>
>> > Is the
>> > input thread still running?  It should be stuck in w32_msg_pump or
>> > w32_wnd_proc.
>>
>> Sounds like Thread 3 from that earlier message.
>>
>> Thread 3 (Thread 8808.0x2bfc):
>> #0  0x00007ffc3eb69844 in ntdll!ZwWaitForAlertByThreadId () from
>> C:\WINDOWS\SYSTEM32\ntdll.dll
>> #1  0x00007ffc3eaefa87 in ntdll!RtlpUnWaitCriticalSection () from
>> C:\WINDOWS\SYSTEM32\ntdll.dll
>> #2  0x00007ffc3eaef98e in ntdll!RtlpUnWaitCriticalSection () from
>> C:\WINDOWS\SYSTEM32\ntdll.dll
>> #3  0x00007ffc3eaef81f in ntdll!RtlpUnWaitCriticalSection () from
>> C:\WINDOWS\SYSTEM32\ntdll.dll
>> #4  0x00007ffc3eaf0ce4 in ntdll!RtlEnterCriticalSection () from
>> C:\WINDOWS\SYSTEM32\ntdll.dll
>> #5  0x00007ffc3eaf0c10 in ntdll!RtlEnterCriticalSection () from
>> C:\WINDOWS\SYSTEM32\ntdll.dll
>> #6  0x0000000400216a9b in post_msg ()
>> #7  0x00000004001f1920 in post_character_message ()
>> #8  0x00000004001fc2b6 in w32_wnd_proc ()
>> #9  0x00007ffc3dbe1c24 in USER32!CallWindowProcW () from
>> C:\WINDOWS\System32\user32.dll
>> #10 0x00007ffc3dbe156c in USER32!DispatchMessageW () from
>> C:\WINDOWS\System32\user32.dll
>> #11 0x00000004001f9dc3 in w32_msg_pump.isra ()
>> #12 0x00000004001fa430 in w32_msg_worker ()
>> #13 0x00007ffc3c038364 in KERNEL32!BaseThreadInitThunk () from
>> C:\WINDOWS\System32\kernel32.dll
>> #14 0x00007ffc3eb270d1 in ntdll!RtlUserThreadStart () from
>> C:\WINDOWS\SYSTEM32\ntdll.dll
>> #15 0x0000000000000000 in ?? ()
>> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>>
>> > The backtrace you show seems to say that SendMessage doesn't return,
>> > which might mean the thread it is sending the message to is either
>> > dead or not responding.  That thread is the input thread.
>>
>> Maybe a deadly embrace then. I'll research how to ask GDB about the
>> state of kernel sync objects.
>
> I think I see what's happening: it's a deadlock.  When you type C-g,
> the input thread (which receives all keyboard input from Windows),
> sets the quit-flag, then attempts to send the C-g character to the
> main thread.  To send the message, it tries to enter critical section,
> and waits for it.  Meanwhile, the main thread tries to tell the input
> thread to draw the scroll bar, and calls SendMessage for that.
> SendMessage waits for the input thread to receive the message, but the
> input thread is stuck waiting for the main thread to exit the critical
> section.

Great! So we should enter the same critical section in the input thread
before calling SendMessage.

(I bet it's not that simple. I'm just trying to join in the fun.)

bug#25279: 26.0.50; Slowdown/crash on certain characters

[Richard Copley]

On 27 December 2016 at 14:32, Richard Copley <rcopley@gmail.com> wrote:
> On 27 December 2016 at 14:15, Eli Zaretskii <eliz@gnu.org> wrote:
>>> From: Richard Copley <rcopley@gmail.com>
>>> Date: Tue, 27 Dec 2016 14:06:27 +0000
>>> Cc: 25279@debbugs.gnu.org
>>>
>>> >> But pressing C-g can cause the indefinite hang in SendMessage seen
>>> >> above.
>>> >
>>> > How many threads are in the program when the hang happens?
>>>
>>> 6, according to an earlier message in this bug.
>>>
>>> > Is the
>>> > input thread still running?  It should be stuck in w32_msg_pump or
>>> > w32_wnd_proc.
>>>
>>> Sounds like Thread 3 from that earlier message.
>>>
>>> Thread 3 (Thread 8808.0x2bfc):
>>> #0  0x00007ffc3eb69844 in ntdll!ZwWaitForAlertByThreadId () from
>>> C:\WINDOWS\SYSTEM32\ntdll.dll
>>> #1  0x00007ffc3eaefa87 in ntdll!RtlpUnWaitCriticalSection () from
>>> C:\WINDOWS\SYSTEM32\ntdll.dll
>>> #2  0x00007ffc3eaef98e in ntdll!RtlpUnWaitCriticalSection () from
>>> C:\WINDOWS\SYSTEM32\ntdll.dll
>>> #3  0x00007ffc3eaef81f in ntdll!RtlpUnWaitCriticalSection () from
>>> C:\WINDOWS\SYSTEM32\ntdll.dll
>>> #4  0x00007ffc3eaf0ce4 in ntdll!RtlEnterCriticalSection () from
>>> C:\WINDOWS\SYSTEM32\ntdll.dll
>>> #5  0x00007ffc3eaf0c10 in ntdll!RtlEnterCriticalSection () from
>>> C:\WINDOWS\SYSTEM32\ntdll.dll
>>> #6  0x0000000400216a9b in post_msg ()
>>> #7  0x00000004001f1920 in post_character_message ()
>>> #8  0x00000004001fc2b6 in w32_wnd_proc ()
>>> #9  0x00007ffc3dbe1c24 in USER32!CallWindowProcW () from
>>> C:\WINDOWS\System32\user32.dll
>>> #10 0x00007ffc3dbe156c in USER32!DispatchMessageW () from
>>> C:\WINDOWS\System32\user32.dll
>>> #11 0x00000004001f9dc3 in w32_msg_pump.isra ()
>>> #12 0x00000004001fa430 in w32_msg_worker ()
>>> #13 0x00007ffc3c038364 in KERNEL32!BaseThreadInitThunk () from
>>> C:\WINDOWS\System32\kernel32.dll
>>> #14 0x00007ffc3eb270d1 in ntdll!RtlUserThreadStart () from
>>> C:\WINDOWS\SYSTEM32\ntdll.dll
>>> #15 0x0000000000000000 in ?? ()
>>> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>>>
>>> > The backtrace you show seems to say that SendMessage doesn't return,
>>> > which might mean the thread it is sending the message to is either
>>> > dead or not responding.  That thread is the input thread.
>>>
>>> Maybe a deadly embrace then. I'll research how to ask GDB about the
>>> state of kernel sync objects.
>>
>> I think I see what's happening: it's a deadlock.  When you type C-g,
>> the input thread (which receives all keyboard input from Windows),
>> sets the quit-flag, then attempts to send the C-g character to the
>> main thread.  To send the message, it tries to enter critical section,
>> and waits for it.  Meanwhile, the main thread tries to tell the input
>> thread to draw the scroll bar, and calls SendMessage for that.
>> SendMessage waits for the input thread to receive the message, but the
>> input thread is stuck waiting for the main thread to exit the critical
>> section.
>
> Great! So we should enter the same critical section in the input thread
> before calling SendMessage.
>
> (I bet it's not that simple. I'm just trying to join in the fun.)

For the record: even being charitable and assuming I meant we should
enter the critical section in the main thread before telling the input
thread to draw the scroll bar, that's stupid and will make Emacs hang
on startup, as soon as it first draws the vertical scroll bar.

I can reproduce the hang on demand now, with the recipe below,
provided Symbola isn't installed, that is, provided MUSIC FLAT SIGN,
RIGHTWARDS DOUBLE ARROW or whatever other characters have the property
that:

> > The fonts Emacs finds for displaying these characters all have
> > non-Unicode registry fields, and that causes Emacs to desperately
> > look for a Unicode font each time it needs to display one of these
> > characters.

From "runemacs -Q":
Type "M-x insert-char RET MUSIC SPC FLAT SPC SIGN RET" (or whatever character).
Observe that moving point past the character is very slow.
In quick succession:
1. Type C-f to move point past the character.
2. Type C-g to signal quit.

bug#25279: 26.0.50; Slowdown/crash on certain characters

[Richard Copley]

> From "runemacs -Q":
> Type "M-x insert-char RET MUSIC SPC FLAT SPC SIGN RET" (or whatever character).
> Observe that moving point past the character is very slow.
> In quick succession:
> 1. Type C-f to move point past the character.
> 2. Type C-g to signal quit.

Here's how to make Emacs hang without the need to uninstall any fonts,
on Windows (not reproducible on GNU/Linux).
1. Type "M-x view-hello-file" (don't press return).
2. In quick succession, type "C-m" and then "C-g". *

(* It is faster to type "C-m C-g" than "RET C-g".)

On 27 December 2016 at 14:15, Eli Zaretskii wrote:
> I think I see what's happening: it's a deadlock.  When you type C-g,
> the input thread (which receives all keyboard input from Windows),
> sets the quit-flag, then attempts to send the C-g character to the
> main thread.  To send the message, it tries to enter critical section,
> and waits for it.  Meanwhile, the main thread tries to tell the input
> thread to draw the scroll bar, and calls SendMessage for that.
> SendMessage waits for the input thread to receive the message, but the
> input thread is stuck waiting for the main thread to exit the critical
> section.

Eli, should I retitle this bug to "26.0.50; calling SendMessage inside
critical section causes deadlock", or close this bug as a duplicate of
the other "slow fonts on Windows" bugs and file a new report about
the hanging?

Emacs master has a pronounced tendency to hang in various other
circumstances too.

bug#25279: 26.0.50; Slowdown/crash on certain characters

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Tue, 21 Feb 2017 20:05:28 +0000
> Cc: 25279@debbugs.gnu.org
> 
> Here's how to make Emacs hang without the need to uninstall any fonts,
> on Windows (not reproducible on GNU/Linux).
> 1. Type "M-x view-hello-file" (don't press return).
> 2. In quick succession, type "C-m" and then "C-g". *

Thanks.

> Eli, should I retitle this bug to "26.0.50; calling SendMessage inside
> critical section causes deadlock", or close this bug as a duplicate of
> the other "slow fonts on Windows" bugs and file a new report about
> the hanging?

The former, I guess.  I will take a look when I have time.

> Emacs master has a pronounced tendency to hang in various other
> circumstances too.

Showing backtraces from the relevant threads when it hangs would be
appreciated.

bug#25279: 26.0.50; Slowdown/crash on certain characters

[Richard Copley]

retitle 25279 26.0.50; calling SendMessage inside critical section
causes deadlock
thanks

On 21 February 2017 at 20:28, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Tue, 21 Feb 2017 20:05:28 +0000
>> Cc: 25279@debbugs.gnu.org
>>
>> Here's how to make Emacs hang without the need to uninstall any fonts,
>> on Windows (not reproducible on GNU/Linux).
>> 1. Type "M-x view-hello-file" (don't press return).
>> 2. In quick succession, type "C-m" and then "C-g". *
>
> Thanks.
>
>> Eli, should I retitle this bug to "26.0.50; calling SendMessage inside
>> critical section causes deadlock", or close this bug as a duplicate of
>> the other "slow fonts on Windows" bugs and file a new report about
>> the hanging?
>
> The former, I guess.  I will take a look when I have time.

Thanks.

>> Emacs master has a pronounced tendency to hang in various other
>> circumstances too.
>
> Showing backtraces from the relevant threads when it hangs would be
> appreciated.

OK, I'll run Emacs in the debugger for a few weeks.

bug#25279: 26.0.50; Slowdown/crash on certain characters

[Richard Copley]

retitle 25279 26.0.50; SendMessage critical section deadlock
thanks

On 21 February 2017 at 20:33, Richard Copley <rcopley@gmail.com> wrote:
> retitle 25279 26.0.50; calling SendMessage inside critical section
> causes deadlock
> thanks
>
> On 21 February 2017 at 20:28, Eli Zaretskii <eliz@gnu.org> wrote:
>>> From: Richard Copley <rcopley@gmail.com>
>>> Date: Tue, 21 Feb 2017 20:05:28 +0000
>>> Cc: 25279@debbugs.gnu.org
>>>
>>> Here's how to make Emacs hang without the need to uninstall any fonts,
>>> on Windows (not reproducible on GNU/Linux).
>>> 1. Type "M-x view-hello-file" (don't press return).
>>> 2. In quick succession, type "C-m" and then "C-g". *
>>
>> Thanks.
>>
>>> Eli, should I retitle this bug to "26.0.50; calling SendMessage inside
>>> critical section causes deadlock", or close this bug as a duplicate of
>>> the other "slow fonts on Windows" bugs and file a new report about
>>> the hanging?
>>
>> The former, I guess.  I will take a look when I have time.
>
> Thanks.
>
>>> Emacs master has a pronounced tendency to hang in various other
>>> circumstances too.
>>
>> Showing backtraces from the relevant threads when it hangs would be
>> appreciated.
>
> OK, I'll run Emacs in the debugger for a few weeks.

bug#25279: 26.0.50; Slowdown/crash on certain characters

[Eli Zaretskii]

> Date: Tue, 21 Feb 2017 22:28:05 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 25279@debbugs.gnu.org
> 
> > From: Richard Copley <rcopley@gmail.com>
> > Date: Tue, 21 Feb 2017 20:05:28 +0000
> > Cc: 25279@debbugs.gnu.org
> > 
> > Here's how to make Emacs hang without the need to uninstall any fonts,
> > on Windows (not reproducible on GNU/Linux).
> > 1. Type "M-x view-hello-file" (don't press return).
> > 2. In quick succession, type "C-m" and then "C-g". *
> 
> Thanks.
> 
> > Eli, should I retitle this bug to "26.0.50; calling SendMessage inside
> > critical section causes deadlock", or close this bug as a duplicate of
> > the other "slow fonts on Windows" bugs and file a new report about
> > the hanging?
> 
> The former, I guess.  I will take a look when I have time.

I think I found the reason: due to C-g, we were jumping to top-level
while in a critical section, which is a very bad idea, because any
non-main thread that tries to acquire the critical section after that
will necessarily hang.

Please try the latest master and see if any such hangs are still
there.

Thanks for the recipe, it made it quite easy to catch the villain
red-handed.

bug#25279: 26.0.50; Slowdown/crash on certain characters

[Richard Copley]

On 23 February 2017 at 16:19, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 21 Feb 2017 22:28:05 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: 25279@debbugs.gnu.org
>>
>> > From: Richard Copley <rcopley@gmail.com>
>> > Date: Tue, 21 Feb 2017 20:05:28 +0000
>> > Cc: 25279@debbugs.gnu.org
>> >
>> > Here's how to make Emacs hang without the need to uninstall any fonts,
>> > on Windows (not reproducible on GNU/Linux).
>> > 1. Type "M-x view-hello-file" (don't press return).
>> > 2. In quick succession, type "C-m" and then "C-g". *
>>
>> Thanks.
>>
>> > Eli, should I retitle this bug to "26.0.50; calling SendMessage inside
>> > critical section causes deadlock", or close this bug as a duplicate of
>> > the other "slow fonts on Windows" bugs and file a new report about
>> > the hanging?
>>
>> The former, I guess.  I will take a look when I have time.
>
> I think I found the reason: due to C-g, we were jumping to top-level
> while in a critical section, which is a very bad idea, because any
> non-main thread that tries to acquire the critical section after that
> will necessarily hang.
>
> Please try the latest master and see if any such hangs are still
> there.

Great, thank you. Sounds like your changes potentially eliminate
a fairly broad class of errors.
In terms of testing I can't say much about any other hangs (I would
if I could!), but that one recipe no longer hangs for me.

> Thanks for the recipe, it made it quite easy to catch the villain
> red-handed.

Nice to know.

bug#25279: 26.0.50; Slowdown/crash on certain characters

[Richard Copley]

I'll send another report if and when I catch another hang.

bug#25279: 26.0.50; Slowdown/crash on certain characters

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Tue, 21 Feb 2017 20:05:28 +0000
> Cc: 25279@debbugs.gnu.org
> 
> Emacs master has a pronounced tendency to hang in various other
> circumstances too.

Are all of them somehow related to C-g typed while Emacs needs to
display unusual characters, per chance?