* bug#25279: 26.0.50; Slowdown/crash on certain characters @ 2016-12-26 20:09 Richard Copley 2016-12-26 20:18 ` Richard Copley 2016-12-26 20:25 ` Eli Zaretskii 0 siblings, 2 replies; 21+ messages in thread From: Richard Copley @ 2016-12-26 20:09 UTC (permalink / raw) To: 25279 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)) ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#25279: 26.0.50; Slowdown/crash on certain characters 2016-12-26 20:09 bug#25279: 26.0.50; Slowdown/crash on certain characters Richard Copley @ 2016-12-26 20:18 ` Richard Copley 2016-12-26 20:25 ` Eli Zaretskii 1 sibling, 0 replies; 21+ messages in thread From: Richard Copley @ 2016-12-26 20:18 UTC (permalink / raw) To: 25279 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)) ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#25279: 26.0.50; Slowdown/crash on certain characters 2016-12-26 20:09 bug#25279: 26.0.50; Slowdown/crash on certain characters Richard Copley 2016-12-26 20:18 ` Richard Copley @ 2016-12-26 20:25 ` Eli Zaretskii 2016-12-26 20:40 ` Richard Copley 1 sibling, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2016-12-26 20:25 UTC (permalink / raw) To: Richard Copley; +Cc: 25279 > 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#25279: 26.0.50; Slowdown/crash on certain characters 2016-12-26 20:25 ` Eli Zaretskii @ 2016-12-26 20:40 ` Richard Copley 2016-12-26 20:49 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Richard Copley @ 2016-12-26 20:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 25279 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! ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#25279: 26.0.50; Slowdown/crash on certain characters 2016-12-26 20:40 ` Richard Copley @ 2016-12-26 20:49 ` Eli Zaretskii 2016-12-26 21:21 ` Richard Copley 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2016-12-26 20:49 UTC (permalink / raw) To: Richard Copley; +Cc: 25279 > 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#25279: 26.0.50; Slowdown/crash on certain characters 2016-12-26 20:49 ` Eli Zaretskii @ 2016-12-26 21:21 ` Richard Copley 2016-12-27 7:21 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Richard Copley @ 2016-12-26 21:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 25279 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#25279: 26.0.50; Slowdown/crash on certain characters 2016-12-26 21:21 ` Richard Copley @ 2016-12-27 7:21 ` Eli Zaretskii [not found] ` <CAPM58oiS8+TuR8WhKZmEZdWY_ac44xLDjnpYAD0aWqU6=mX7eg@mail.gmail.com> 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2016-12-27 7:21 UTC (permalink / raw) To: Richard Copley; +Cc: 25279 > 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <CAPM58oiS8+TuR8WhKZmEZdWY_ac44xLDjnpYAD0aWqU6=mX7eg@mail.gmail.com>]
* bug#25279: Fwd: bug#25279: 26.0.50; Slowdown/crash on certain characters [not found] ` <CAPM58oiS8+TuR8WhKZmEZdWY_ac44xLDjnpYAD0aWqU6=mX7eg@mail.gmail.com> @ 2016-12-27 13:51 ` Richard Copley [not found] ` <CAPM58oioMPAo=x8F1whs5YS3RMwceoadAT9TN7Macbx=SaxyJA@mail.gmail.com> 1 sibling, 0 replies; 21+ messages in thread From: Richard Copley @ 2016-12-27 13:51 UTC (permalink / raw) To: 25279 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <CAPM58oioMPAo=x8F1whs5YS3RMwceoadAT9TN7Macbx=SaxyJA@mail.gmail.com>]
* bug#25279: Fwd: bug#25279: 26.0.50; Slowdown/crash on certain characters [not found] ` <CAPM58oioMPAo=x8F1whs5YS3RMwceoadAT9TN7Macbx=SaxyJA@mail.gmail.com> @ 2016-12-27 13:53 ` Richard Copley [not found] ` <838tr1wlg4.fsf@gnu.org> 1 sibling, 0 replies; 21+ messages in thread From: Richard Copley @ 2016-12-27 13:53 UTC (permalink / raw) To: 25279 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?) ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <838tr1wlg4.fsf@gnu.org>]
[parent not found: <CAPM58og6d1EqTEyMy6df27DXB_ERYOD5=pmFHC9MmoFmq+CDgw@mail.gmail.com>]
[parent not found: <837f6lwkju.fsf@gnu.org>]
* bug#25279: 26.0.50; Slowdown/crash on certain characters [not found] ` <837f6lwkju.fsf@gnu.org> @ 2016-12-27 14:06 ` Richard Copley 2016-12-27 14:15 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Richard Copley @ 2016-12-27 14:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 25279 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#25279: 26.0.50; Slowdown/crash on certain characters 2016-12-27 14:06 ` Richard Copley @ 2016-12-27 14:15 ` Eli Zaretskii 2016-12-27 14:32 ` Richard Copley 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2016-12-27 14:15 UTC (permalink / raw) To: Richard Copley; +Cc: 25279 > 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#25279: 26.0.50; Slowdown/crash on certain characters 2016-12-27 14:15 ` Eli Zaretskii @ 2016-12-27 14:32 ` Richard Copley 2016-12-27 21:15 ` Richard Copley 0 siblings, 1 reply; 21+ messages in thread From: Richard Copley @ 2016-12-27 14:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 25279 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.) ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#25279: 26.0.50; Slowdown/crash on certain characters 2016-12-27 14:32 ` Richard Copley @ 2016-12-27 21:15 ` Richard Copley 2017-02-21 20:05 ` Richard Copley 0 siblings, 1 reply; 21+ messages in thread From: Richard Copley @ 2016-12-27 21:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 25279 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#25279: 26.0.50; Slowdown/crash on certain characters 2016-12-27 21:15 ` Richard Copley @ 2017-02-21 20:05 ` Richard Copley 2017-02-21 20:28 ` Eli Zaretskii 2017-02-23 15:22 ` Eli Zaretskii 0 siblings, 2 replies; 21+ messages in thread From: Richard Copley @ 2017-02-21 20:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 25279 > 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#25279: 26.0.50; Slowdown/crash on certain characters 2017-02-21 20:05 ` Richard Copley @ 2017-02-21 20:28 ` Eli Zaretskii 2017-02-21 20:33 ` Richard Copley 2017-02-23 16:19 ` Eli Zaretskii 2017-02-23 15:22 ` Eli Zaretskii 1 sibling, 2 replies; 21+ messages in thread From: Eli Zaretskii @ 2017-02-21 20:28 UTC (permalink / raw) To: Richard Copley; +Cc: 25279 > 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#25279: 26.0.50; Slowdown/crash on certain characters 2017-02-21 20:28 ` Eli Zaretskii @ 2017-02-21 20:33 ` Richard Copley 2017-02-21 20:38 ` Richard Copley 2017-02-23 16:19 ` Eli Zaretskii 1 sibling, 1 reply; 21+ messages in thread From: Richard Copley @ 2017-02-21 20:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 25279 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#25279: 26.0.50; Slowdown/crash on certain characters 2017-02-21 20:33 ` Richard Copley @ 2017-02-21 20:38 ` Richard Copley 0 siblings, 0 replies; 21+ messages in thread From: Richard Copley @ 2017-02-21 20:38 UTC (permalink / raw) To: GNU bug tracker automated control server; +Cc: 25279 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#25279: 26.0.50; Slowdown/crash on certain characters 2017-02-21 20:28 ` Eli Zaretskii 2017-02-21 20:33 ` Richard Copley @ 2017-02-23 16:19 ` Eli Zaretskii 2017-02-23 19:15 ` Richard Copley 1 sibling, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2017-02-23 16:19 UTC (permalink / raw) To: rcopley; +Cc: 25279 > 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#25279: 26.0.50; Slowdown/crash on certain characters 2017-02-23 16:19 ` Eli Zaretskii @ 2017-02-23 19:15 ` Richard Copley 2017-02-23 19:20 ` Richard Copley 0 siblings, 1 reply; 21+ messages in thread From: Richard Copley @ 2017-02-23 19:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 25279 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#25279: 26.0.50; Slowdown/crash on certain characters 2017-02-23 19:15 ` Richard Copley @ 2017-02-23 19:20 ` Richard Copley 0 siblings, 0 replies; 21+ messages in thread From: Richard Copley @ 2017-02-23 19:20 UTC (permalink / raw) To: Eli Zaretskii, 25279-done I'll send another report if and when I catch another hang. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#25279: 26.0.50; Slowdown/crash on certain characters 2017-02-21 20:05 ` Richard Copley 2017-02-21 20:28 ` Eli Zaretskii @ 2017-02-23 15:22 ` Eli Zaretskii 1 sibling, 0 replies; 21+ messages in thread From: Eli Zaretskii @ 2017-02-23 15:22 UTC (permalink / raw) To: Richard Copley; +Cc: 25279 > 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? ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2017-02-23 19:20 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-12-26 20:09 bug#25279: 26.0.50; Slowdown/crash on certain characters Richard Copley 2016-12-26 20:18 ` Richard Copley 2016-12-26 20:25 ` Eli Zaretskii 2016-12-26 20:40 ` Richard Copley 2016-12-26 20:49 ` Eli Zaretskii 2016-12-26 21:21 ` Richard Copley 2016-12-27 7:21 ` Eli Zaretskii [not found] ` <CAPM58oiS8+TuR8WhKZmEZdWY_ac44xLDjnpYAD0aWqU6=mX7eg@mail.gmail.com> 2016-12-27 13:51 ` bug#25279: Fwd: " Richard Copley [not found] ` <CAPM58oioMPAo=x8F1whs5YS3RMwceoadAT9TN7Macbx=SaxyJA@mail.gmail.com> 2016-12-27 13:53 ` Richard Copley [not found] ` <838tr1wlg4.fsf@gnu.org> [not found] ` <CAPM58og6d1EqTEyMy6df27DXB_ERYOD5=pmFHC9MmoFmq+CDgw@mail.gmail.com> [not found] ` <837f6lwkju.fsf@gnu.org> 2016-12-27 14:06 ` Richard Copley 2016-12-27 14:15 ` Eli Zaretskii 2016-12-27 14:32 ` Richard Copley 2016-12-27 21:15 ` Richard Copley 2017-02-21 20:05 ` Richard Copley 2017-02-21 20:28 ` Eli Zaretskii 2017-02-21 20:33 ` Richard Copley 2017-02-21 20:38 ` Richard Copley 2017-02-23 16:19 ` Eli Zaretskii 2017-02-23 19:15 ` Richard Copley 2017-02-23 19:20 ` Richard Copley 2017-02-23 15:22 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.