bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Sam Steingold]

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

Emacs hangs with a yellow triangle in the middle of the frame
(indicating ding) but C-g and C-] do not interrupt.
CPU usage is at 90%.
The only way out is "force quit" in activity monitor.
"sample" is attached
I seem to be able to reproduce the hang by trying to enter a specific
article in an nntp group.
Thanks.



[-- Attachment #2: activity monitor sample --]
[-- Type: application/octet-stream, Size: 75077 bytes --]

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


In GNU Emacs 26.0.50 (build 1, x86_64-apple-darwin16.7.0, NS appkit-1504.83 Version 10.12.6 (Build 16G29))
 of 2017-08-21 built on Clr-Sam.local
Repository revision: 9840499564c90c43b1d269154593ebe57a7cb9b0
Windowing system distributor 'Apple', version 10.3.1504
Recent messages:
Shell native completion is enabled.
Flymake mode disabled in current buffer
Can’t guess python-indent-offset, using defaults: 4
Sent: ## poor man's notebook...
Quit
mouse-2: visit this file in other window [3 times]
View mode: type C-h for help, h for commands, q to quit.
scroll-up-command: End of buffer [7 times]
Mark set
mouse-2: visit this file in other window

Configured using:
 'configure --with-mailutils --with-ns
 PKG_CONFIG_PATH=/usr/local/opt/libxml2/lib/pkgconfig:/usr/local/opt/imagemagick/lib/pkgconfig/
 --without-makeinfo'

Configured features:
JPEG NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

Important settings:
  value of $LANG: C
  locale-coding-system: utf-8-unix

Major mode: Dired by name

Minor modes in effect:
  diff-auto-refine-mode: t
  shell-dirtrack-mode: t
  rcirc-track-minor-mode: t
  pyvenv-mode: t
  global-edit-server-edit-mode: t
  global-semanticdb-minor-mode: t
  global-semantic-idle-scheduler-mode: t
  which-function-mode: t
  url-handler-mode: t
  semantic-mode: t
  show-paren-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t

Load-path shadows:
None found.

Features:
(shadow sort bbdb-message mailalias cookie1 mail-extr gnus-msg gnus-art
mm-uu mml2015 mm-view mml-smime smime dig gnus-sum gnus-group gnus-undo
gnus-start gnus-cloud nnimap nnmail mail-source tls gnutls utf7 netrc
nnoo gnus-spec gnus-int gnus-range gnus-win emacsbug message subr-x
rfc822 mml mml-sec epa epg epg-config mm-decode mm-bodies mm-encode
mail-parse rfc2231 gmm-utils mailheader sendmail add-log view cl-print
remember conf-mode score-mode dired-aux dired dired-loaddefs
semantic/html cursor-sensor mhtml-mode css-mode smie color eww puny
mm-url url-queue url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util mailcap shr svg xml
browse-url js cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs sgml-mode dom flyspell ispell
company-capf company-semantic vc-dir ewoc vc semantic/tag-file
semantic/imenu semantic/sort vc-git semantic/db-file data-debug
cedet-files semantic/wisent/python semantic/decorate/include
semantic/db-find semantic/db-ref semantic/decorate/mode
semantic/decorate pulse semantic/dep semantic/wisent/python-wy
semantic/wisent semantic/wisent/wisent rx company-oddmuse
company-keywords company-etags company-gtags company-dabbrev-code
company-dabbrev company-files company-cmake company-xcode company-clang
company-eclim company-template company-css company-nxml company-bbdb
cl-extra yasnippet flymake flymake-proc flymake-ui company pcase
help-fns radix-tree help-mode elpy find-file-in-project ivy delsel
ivy-overlay ffap thingatpt diff-mode elpy-profile elpy-django easy-mmode
s elpy-refactor derived edmacro kmacro ido grep compile files-x etags
xref project cus-edit python tramp-sh tramp tramp-compat tramp-loaddefs
trampver shell pcomplete parse-time format-spec comint ansi-color
elec-pair rcirc ring vc-dispatcher vc-hg warnings midnight ein-loaddefs
pyvenv json map gnus nnheader gnus-util rmail rmail-loaddefs rfc2047
rfc2045 ietf-drums mail-utils mm-util mail-prsvr wid-edit bbdb-mua
bbdb-com crm mailabbrev bbdb-loaddefs bbdb bbdb-site timezone
edit-server advice server finder-inf info package seq semantic/db-mode
semantic/db eieio-base semantic/idle semantic/format ezimage
semantic/tag-ls semantic/find semantic/ctxt which-func imenu
url-handlers url-parse auth-source cl-seq password-cache url-vars
semantic/util-modes easymenu semantic/util semantic semantic/tag
semantic/lex semantic/fw eieio byte-opt bytecomp byte-compile cconv
eieio-core cl-macs eieio-loaddefs mode-local find-func cedet paren
help-at-pt desktop frameset cus-start cus-load cl gv cl-loaddefs cl-lib
time-date tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/ns-win ns-win ucs-normalize mule-util
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 charprop 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 kqueue cocoa ns multi-tty make-network-process emacs)

Memory information:
((conses 16 634668 35070)
 (symbols 48 45010 1)
 (miscs 40 13275 52)
 (strings 32 220769 13312)
 (string-bytes 1 5560902)
 (vectors 16 90188)
 (vector-slots 8 1891734 7590)
 (floats 8 467 735)
 (intervals 56 6832 0)
 (buffers 992 60))

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://think-israel.org
http://americancensorship.org https://ffii.org http://honestreporting.com
My suicidal thoughts are killing me.

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Date: Mon, 21 Aug 2017 12:09:13 -0400
> 
> Emacs hangs with a yellow triangle in the middle of the frame
> (indicating ding) but C-g and C-] do not interrupt.
> CPU usage is at 90%.
> The only way out is "force quit" in activity monitor.
> "sample" is attached
> I seem to be able to reproduce the hang by trying to enter a specific
> article in an nntp group.

Not sure I understand: do you mean that to reproduce the hang one
should just visit this file from "emacs -Q"?  Because if so, Emacs
doesn't hang for me here.

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Sam Steingold]

> * Eli Zaretskii <ryvm@tah.bet> [2017-08-21 19:24:47 +0300]:
>
>> From: Sam Steingold <sds@gnu.org>
>> Date: Mon, 21 Aug 2017 12:09:13 -0400
>> 
>> Emacs hangs with a yellow triangle in the middle of the frame
>> (indicating ding) but C-g and C-] do not interrupt.
>> CPU usage is at 90%.
>> The only way out is "force quit" in activity monitor.
>> "sample" is attached
>> I seem to be able to reproduce the hang by trying to enter a specific
>> article in an nntp group.
>
> Not sure I understand: do you mean that to reproduce the hang one
> should just visit this file from "emacs -Q"?  Because if so, Emacs
> doesn't hang for me here.

Alas, no.
I have no idea how to reproduce this easily.
It might work like this:
start gnus
open newsgroup "nntp+news.gwene.org:gwene.com.stackexchange.history"
in *Summary* buffer, find article with subject
"Why, in ancient battles, did being encircled mean defeat?"
view it by hitting RET.

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net https://ffii.org
http://honestreporting.com http://think-israel.org https://jihadwatch.org
Takeoffs are optional.  Landings are mandatory.

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Cc: 28176@debbugs.gnu.org
> Date: Mon, 21 Aug 2017 13:23:23 -0400
> 
> I have no idea how to reproduce this easily.
> It might work like this:
> start gnus
> open newsgroup "nntp+news.gwene.org:gwene.com.stackexchange.history"
> in *Summary* buffer, find article with subject
> "Why, in ancient battles, did being encircled mean defeat?"
> view it by hitting RET.

Can you show a backtrace when it hangs like that?

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Sam Steingold]

> * Eli Zaretskii <ryvm@tah.bet> [2017-08-21 20:41:31 +0300]:
>
>> From: Sam Steingold <sds@gnu.org>
>> Cc: 28176@debbugs.gnu.org
>> Date: Mon, 21 Aug 2017 13:23:23 -0400
>> 
>> I have no idea how to reproduce this easily.
>> It might work like this:
>> start gnus
>> open newsgroup "nntp+news.gwene.org:gwene.com.stackexchange.history"
>> in *Summary* buffer, find article with subject
>> "Why, in ancient battles, did being encircled mean defeat?"
>> view it by hitting RET.
>
> Can you show a backtrace when it hangs like that?

Alas, no: I cannot break out of the hang.
As I wrote:

Emacs hangs with a yellow triangle in the middle of the frame
(indicating ding) but C-g and C-] do not interrupt.
CPU usage is at 90%.
The only way out is "force quit" in activity monitor.

I.e., the only way out is "kill -9".

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://honestreporting.com
http://camera.org http://islamexposedonline.com http://americancensorship.org
Daddy, what does "format disk c: complete" mean?

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Cc: 28176@debbugs.gnu.org
> Date: Mon, 21 Aug 2017 14:46:30 -0400
> 
> > Can you show a backtrace when it hangs like that?
> 
> Alas, no: I cannot break out of the hang.

You could start Emacs under a debugger to begin with, and when Emacs
hangs, type "kill -USR1".

> Emacs hangs with a yellow triangle in the middle of the frame
> (indicating ding) but C-g and C-] do not interrupt.
> CPU usage is at 90%.

This most probably means Emacs is signaling an error in redisplay
code, which causes an infinite loop of signaling an error, then
redisplaying, then signaling an error again, and so on and so forth.
Still, a C-level backtrace might show which Lisp code runs and what C
call chain is involved.  So it's useful information, if you can
provide it.

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Cc: 28176@debbugs.gnu.org
> Date: Mon, 21 Aug 2017 13:23:23 -0400
> 
> start gnus
> open newsgroup "nntp+news.gwene.org:gwene.com.stackexchange.history"
> in *Summary* buffer, find article with subject
> "Why, in ancient battles, did being encircled mean defeat?"
> view it by hitting RET.

Would you please provide more detailed instructions?  I don't use
Gnus, so after typing "M-x gnus RET" I'm lost.  How do I "open a
newsgroup"?  I tried subscribing to this group from the menu bar, but
I couldn't open that group after subscribing.  I guess I didn't select
a correct server or something?

Thanks.

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Sam Steingold]

> * Eli Zaretskii <ryvm@tah.bet> [2017-08-21 22:03:30 +0300]:
>
>> From: Sam Steingold <sds@gnu.org>
>> Cc: 28176@debbugs.gnu.org
>> Date: Mon, 21 Aug 2017 14:46:30 -0400
>> 
>> > Can you show a backtrace when it hangs like that?
>> 
>> Alas, no: I cannot break out of the hang.
>
> You could start Emacs under a debugger to begin with, and when Emacs
> hangs, type "kill -USR1".
>
>> Emacs hangs with a yellow triangle in the middle of the frame
>> (indicating ding) but C-g and C-] do not interrupt.
>> CPU usage is at 90%.
>
> This most probably means Emacs is signaling an error in redisplay
> code, which causes an infinite loop of signaling an error, then
> redisplaying, then signaling an error again, and so on and so forth.
> Still, a C-level backtrace might show which Lisp code runs and what C
> call chain is involved.  So it's useful information, if you can
> provide it.

--8<---------------cut here---------------start------------->8---
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x0000000100030788 emacs`display_mode_element(it=0x00007fff5fbf8258, depth=8, field_width=0, precision=<unavailable>, elt=4328980291, props=4412454691, risky=<unavailable>) at xdisp.c:23603 [opt]
    frame #1: 0x00000001000309d0 emacs`display_mode_element(it=0x00007fff5fbf8258, depth=<unavailable>, field_width=0, precision=<unavailable>, elt=<unavailable>, props=4412454691, risky=<unavailable>) at xdisp.c:23692 [opt]
    frame #2: 0x00000001000309d0 emacs`display_mode_element(it=0x00007fff5fbf8258, depth=<unavailable>, field_width=0, precision=<unavailable>, elt=<unavailable>, props=4412454691, risky=<unavailable>) at xdisp.c:23692 [opt]
    frame #3: 0x0000000100030b05 emacs`display_mode_element(it=0x00007fff5fbf8258, depth=4, field_width=0, precision=-66, elt=<unavailable>, props=0, risky=<unavailable>) at xdisp.c:23629 [opt]
    frame #4: 0x00000001000309d0 emacs`display_mode_element(it=0x00007fff5fbf8258, depth=<unavailable>, field_width=0, precision=<unavailable>, elt=<unavailable>, props=0, risky=<unavailable>) at xdisp.c:23692 [opt]
    frame #5: 0x00000001000309d0 emacs`display_mode_element(it=0x00007fff5fbf8258, depth=<unavailable>, field_width=0, precision=<unavailable>, elt=<unavailable>, props=0, risky=<unavailable>) at xdisp.c:23692 [opt]
    frame #6: 0x000000010001bf09 emacs`display_mode_line(w=0x000000010482ea30, face_id=MODE_LINE_FACE_ID, format=4315887955) at xdisp.c:23211 [opt]
    frame #7: 0x000000010004b2e4 emacs`display_mode_lines(w=0x000000010482ea30) at xdisp.c:23146 [opt]
    frame #8: 0x000000010005180f emacs`redisplay_window(window=4370655797, just_this_one_p=<unavailable>) at xdisp.c:17397 [opt]
    frame #9: 0x000000010004db36 emacs`redisplay_window_0(window=<unavailable>) at xdisp.c:14780 [opt]
  * frame #10: 0x0000000100136e86 emacs`internal_condition_case_1(bfun=(emacs`redisplay_window_0 at xdisp.c:14779), arg=4370655797, handlers=<unavailable>, hfun=(emacs`redisplay_window_error at xdisp.c:14771)) at eval.c:1347 [opt]
    frame #11: 0x000000010004d19d emacs`redisplay_windows(window=<unavailable>) at xdisp.c:14760 [opt]
    frame #12: 0x000000010004d164 emacs`redisplay_windows(window=<unavailable>) at xdisp.c:14754 [opt]
    frame #13: 0x00000001000282af emacs`redisplay_internal at xdisp.c:14249 [opt]
    frame #14: 0x00000001000bf92e emacs`read_char(commandflag=1, map=4316828339, prev_event=0, used_mouse_menu=0x00007fff5fbfeabf, end_time=0x0000000000000000) at keyboard.c:2484 [opt]
    frame #15: 0x00000001000bd40a emacs`read_key_sequence(keybuf=<unavailable>, bufsize=30, prompt=<unavailable>, dont_downcase_last=<unavailable>, can_return_switch_frame=<unavailable>, fix_current_buffer=<unavailable>, prevent_redisplay=<unavailable>) at keyboard.c:9151 [opt]
    frame #16: 0x00000001000bbc02 emacs`command_loop_1 at keyboard.c:1372 [opt]
    frame #17: 0x0000000100136e12 emacs`internal_condition_case(bfun=(emacs`command_loop_1 at keyboard.c:1263), handlers=<unavailable>, hfun=(emacs`cmd_error at keyboard.c:942)) at eval.c:1323 [opt]
    frame #18: 0x00000001000ca800 emacs`command_loop_2(ignore=<unavailable>) at keyboard.c:1114 [opt]
    frame #19: 0x00000001001366b9 emacs`internal_catch(tag=<unavailable>, func=(emacs`command_loop_2 at keyboard.c:1110), arg=0) at eval.c:1088 [opt]
    frame #20: 0x00000001000bae5e emacs`command_loop at keyboard.c:1093 [opt]
    frame #21: 0x00000001000bad6f emacs`recursive_edit_1 at keyboard.c:699 [opt]
    frame #22: 0x00000001000bafa3 emacs`Frecursive_edit at keyboard.c:770 [opt]
    frame #23: 0x00000001000b9bb7 emacs`main(argc=0, argv=<unavailable>) at emacs.c:1706 [opt]
    frame #24: 0x00007fffae679235 libdyld.dylib`start + 1
    frame #25: 0x00007fffae679235 libdyld.dylib`start + 1
--8<---------------cut here---------------end--------------->8---




-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net https://ffii.org
http://mideasttruth.com http://no2bds.org http://think-israel.org
Life is like a diaper -- short and loaded.

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Sam Steingold]

> * Eli Zaretskii <ryvm@tah.bet> [2017-08-21 22:10:21 +0300]:
>
>> From: Sam Steingold <sds@gnu.org>
>> Cc: 28176@debbugs.gnu.org
>> Date: Mon, 21 Aug 2017 13:23:23 -0400
>> 
>> start gnus
>> open newsgroup "nntp+news.gwene.org:gwene.com.stackexchange.history"
>> in *Summary* buffer, find article with subject
>> "Why, in ancient battles, did being encircled mean defeat?"
>> view it by hitting RET.
>
> Would you please provide more detailed instructions?

emacs -Q
M-x gnus
^ ; gnus-group-enter-server-mode
a ; gnus-server-add-server
nntp ; method
news.gwene.org ; server
hit RET on the news.gwene.org line in the server line
after a while you get the huge list of newsgroups.
search for "stackexchange.history"
hit enter, get a list of articles in history.
search for "encircled".
hit enter, get a hang.

note that this might be macos-specific ;-(

Thank you for your patient attention.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://iris.org.il
http://no2bds.org https://ffii.org http://americancensorship.org
When you talk to God, it's prayer; when He talks to you, it's schizophrenia.

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Cc: 28176@debbugs.gnu.org
> Date: Mon, 21 Aug 2017 15:44:53 -0400
> 
> emacs -Q
> M-x gnus
> ^ ; gnus-group-enter-server-mode
> a ; gnus-server-add-server
> nntp ; method
> news.gwene.org ; server
> hit RET on the news.gwene.org line in the server line
> after a while you get the huge list of newsgroups.
> search for "stackexchange.history"
> hit enter, get a list of articles in history.
> search for "encircled".
> hit enter, get a hang.

Thanks.  Unfortunately, it doesn't hang for me.

> note that this might be macos-specific ;-(

Maybe it is.  Can someone else reproduce this, on macOS or elsewhere?

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Cc: 28176@debbugs.gnu.org
> Date: Mon, 21 Aug 2017 15:40:41 -0400
> 
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
>     frame #0: 0x0000000100030788 emacs`display_mode_element(it=0x00007fff5fbf8258, depth=8, field_width=0, precision=<unavailable>, elt=4328980291, props=4412454691, risky=<unavailable>) at xdisp.c:23603 [opt]
>     frame #1: 0x00000001000309d0 emacs`display_mode_element(it=0x00007fff5fbf8258, depth=<unavailable>, field_width=0, precision=<unavailable>, elt=<unavailable>, props=4412454691, risky=<unavailable>) at xdisp.c:23692 [opt]
>     frame #2: 0x00000001000309d0 emacs`display_mode_element(it=0x00007fff5fbf8258, depth=<unavailable>, field_width=0, precision=<unavailable>, elt=<unavailable>, props=4412454691, risky=<unavailable>) at xdisp.c:23692 [opt]
>     frame #3: 0x0000000100030b05 emacs`display_mode_element(it=0x00007fff5fbf8258, depth=4, field_width=0, precision=-66, elt=<unavailable>, props=0, risky=<unavailable>) at xdisp.c:23629 [opt]
>     frame #4: 0x00000001000309d0 emacs`display_mode_element(it=0x00007fff5fbf8258, depth=<unavailable>, field_width=0, precision=<unavailable>, elt=<unavailable>, props=0, risky=<unavailable>) at xdisp.c:23692 [opt]
>     frame #5: 0x00000001000309d0 emacs`display_mode_element(it=0x00007fff5fbf8258, depth=<unavailable>, field_width=0, precision=<unavailable>, elt=<unavailable>, props=0, risky=<unavailable>) at xdisp.c:23692 [opt]
>     frame #6: 0x000000010001bf09 emacs`display_mode_line(w=0x000000010482ea30, face_id=MODE_LINE_FACE_ID, format=4315887955) at xdisp.c:23211 [opt]
>     frame #7: 0x000000010004b2e4 emacs`display_mode_lines(w=0x000000010482ea30) at xdisp.c:23146 [opt]
>     frame #8: 0x000000010005180f emacs`redisplay_window(window=4370655797, just_this_one_p=<unavailable>) at xdisp.c:17397 [opt]

This just says that Emacs was in redisplay, displaying the mode line
in some window.

Do you always see this exact backtrace, with the same function calls
and the same arguments, when you interrupt Emacs that hangs like this?
Or does the backtrace look different every time?

Thanks.

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Sam Steingold]

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

here is the backtrace from an identical hang with a different article in
the same group:

2017-08-22 14:10:48.609113-0400 emacs[16623:7011753] [general] Connection
to 'pboard' server had an error: <error: 0x7fffb7597ca0> { count = 1,
transaction: 0, voucher = 0x0, contents =
        "XPCErrorDescription" => <string: 0x7fffb7597f18> { length = 18,
contents = "Connection invalid" }
}
2017-08-22 14:11:02.771791-0400 emacs[16623:7011721] Detected potentially
harmful notification post rate of 229.322 notifications per second
2017-08-22 14:11:12.773714-0400 emacs[16623:7011721] Detected potentially
harmful notification post rate of 300.907 notifications per second
2017-08-22 14:11:22.774338-0400 emacs[16623:7011721] Detected potentially
harmful notification post rate of 280.44 notifications per second
2017-08-22 14:11:32.774777-0400 emacs[16623:7011721] Detected potentially
harmful notification post rate of 290.527 notifications per second
emacs was compiled with optimization - stepping may behave oddly; variables
may not be available.
Process 16623 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP

    frame #0: 0x00000001001a4de9 emacs`lookup_image [inlined]
search_image_cache(f=0x000000010305afa8, spec=4358862915,
hash=4195912884339560560) at image.c:1454 [opt]

   1451
   1452   for (img = c->buckets[i]; img; img = img->next)

   1453     if (img->hash == hash
-> 1454         && !NILP (Fequal (img->spec, spec))
   1455         && img->frame_foreground == FRAME_FOREGROUND_PIXEL (f)

   1456         && img->frame_background == FRAME_BACKGROUND_PIXEL (f))

   1457       break;
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP

  * frame #0: 0x00000001001a4de9 emacs`lookup_image [inlined]
search_image_cache(f=0x000000010305afa8, spec=4358862915,
hash=4195912884339560560) at image.c:1454 [opt]

    frame #1: 0x00000001001a4d82 emacs`lookup_image(f=0x000000010305afa8,
spec=4358862915) at image.c:1739 [opt]

    frame #2: 0x0000000100044a68
emacs`handle_single_display_spec(it=<unavailable>, spec=<unavailable>,
object=<unavailable>, overlay=<unavailable>, position=<unavailable>,
bufpos=<unavailable>, display_replaced=<unavailable>,
frame_window_p=<unavailable>) at xdisp.c:5299 [opt]

    frame #3: 0x000000010001dd85
emacs`handle_display_spec(it=0x00007fff5fbf8280, spec=4358862915,
object=4523100261, overlay=0, position=0x00007fff5fbf83b8, bufpos=1765,
frame_window_p=<unavailable>) at xdisp.c:4800 [opt]

    frame #4: 0x00000001000452e1
emacs`handle_display_prop(it=0x00007fff5fbf8280) at xdisp.c:4719 [opt]


    frame #5: 0x000000010004544b emacs`handle_stop(it=0x00007fff5fbf8280)
at xdisp.c:3425 [opt]
    frame #6: 0x0000000100048434
emacs`next_element_from_buffer(it=0x00007fff5fbf8280) at xdisp.c:8398 [opt]


    frame #7: 0x000000010001c6c2
emacs`get_next_display_element(it=0x00007fff5fbf8280) at xdisp.c:6992 [opt]


    frame #8: 0x000000010002ab68 emacs`display_line(it=0x00007fff5fbf8280,
cursor_vpos=<unavailable>) at xdisp.c:21318 [opt]

    frame #9: 0x000000010002a508 emacs`try_window(window=<unavailable>,
pos=(charpos = 921, bytepos = 921), flags=<unavailable>) at xdisp.c:17573
[opt]
    frame #10: 0x000000010004f8e0 emacs`redisplay_window(window=4356634629,
just_this_one_p=<unavailable>) at xdisp.c:17020 [opt]

    frame #11: 0x000000010004db36
emacs`redisplay_window_0(window=<unavailable>) at xdisp.c:14780 [opt]

                       frame #12: 0x0000000100136e86
emacs`internal_condition_case_1(bfun=(emacs`redisplay_window_0 at
xdisp.c:14779), arg=4356634629, handlers=<unavailable>,
hfun=(emacs`redisplay_window_error at xdisp.c:14771)) at eval.c:1347 [opt]

    frame #13: 0x000000010004d19d
emacs`redisplay_windows(window=<unavailable>) at xdisp.c:14760 [opt]


    frame #14: 0x000000010004d164
emacs`redisplay_windows(window=<unavailable>) at xdisp.c:14754 [opt]


    frame #15: 0x00000001000282af emacs`redisplay_internal at xdisp.c:14249
[opt]
    frame #16: 0x00000001000bf92e emacs`read_char(commandflag=1,
map=4351707683, prev_event=0, used_mouse_menu=0x00007fff5fbfeabf,
end_time=0x0000000000000000) at keyboard.c:2484 [opt]
    frame #17: 0x00000001000bd40a
emacs`read_key_sequence(keybuf=<unavailable>, bufsize=30,
prompt=<unavailable>, dont_downcase_last=<unavailable>,
can_return_switch_frame=<unavailable>, fix_current_buffer=<unavailable>,
prevent_redisplay=<unavailable>) at keyboard.c:9151 [opt]

    frame #18: 0x00000001000bbc02 emacs`command_loop_1 at keyboard.c:1372
[opt]
    frame #19: 0x0000000100136e12
emacs`internal_condition_case(bfun=(emacs`command_loop_1 at
keyboard.c:1263), handlers=<unavailable>, hfun=(emacs`cmd_error at
keyboard.c:942)) at eval.c:1323 [opt]
    frame #20: 0x00000001000ca800
emacs`command_loop_2(ignore=<unavailable>) at keyboard.c:1114 [opt]
    frame #21: 0x00000001001366b9 emacs`internal_catch(tag=<unavailable>,
func=(emacs`command_loop_2 at keyboard.c:1110), arg=0) at eval.c:1088 [opt]

    frame #22: 0x00000001000bae5e emacs`command_loop at keyboard.c:1093
[opt]
    frame #23: 0x00000001000bad6f emacs`recursive_edit_1 at keyboard.c:699
[opt]
    frame #24: 0x00000001000bafa3 emacs`Frecursive_edit at keyboard.c:770
[opt]
    frame #25: 0x00000001000b9bb7 emacs`main(argc=0, argv=<unavailable>) at
emacs.c:1706 [opt]
    frame #26: 0x00007fffae679235 libdyld.dylib`start + 1

    frame #27: 0x00007fffae679235 libdyld.dylib`start + 1



On Tue, Aug 22, 2017 at 11:09 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Sam Steingold <sds@gnu.org>
> > Cc: 28176@debbugs.gnu.org
> > Date: Mon, 21 Aug 2017 15:40:41 -0400
> >
> > (lldb) bt
> > * thread #1, queue = 'com.apple.main-thread', stop reason = signal
> SIGSTOP
> >     frame #0: 0x0000000100030788 emacs`display_mode_element(it=0x00007fff5fbf8258,
> depth=8, field_width=0, precision=<unavailable>, elt=4328980291, props=
> 4412454691, risky=<unavailable>) at xdisp.c:23603 [opt]
> >     frame #1: 0x00000001000309d0 emacs`display_mode_element(it=0x00007fff5fbf8258,
> depth=<unavailable>, field_width=0, precision=<unavailable>,
> elt=<unavailable>, props=4412454691, risky=<unavailable>) at xdisp.c:23692
> [opt]
> >     frame #2: 0x00000001000309d0 emacs`display_mode_element(it=0x00007fff5fbf8258,
> depth=<unavailable>, field_width=0, precision=<unavailable>,
> elt=<unavailable>, props=4412454691, risky=<unavailable>) at xdisp.c:23692
> [opt]
> >     frame #3: 0x0000000100030b05 emacs`display_mode_element(it=0x00007fff5fbf8258,
> depth=4, field_width=0, precision=-66, elt=<unavailable>, props=0,
> risky=<unavailable>) at xdisp.c:23629 [opt]
> >     frame #4: 0x00000001000309d0 emacs`display_mode_element(it=0x00007fff5fbf8258,
> depth=<unavailable>, field_width=0, precision=<unavailable>,
> elt=<unavailable>, props=0, risky=<unavailable>) at xdisp.c:23692 [opt]
> >     frame #5: 0x00000001000309d0 emacs`display_mode_element(it=0x00007fff5fbf8258,
> depth=<unavailable>, field_width=0, precision=<unavailable>,
> elt=<unavailable>, props=0, risky=<unavailable>) at xdisp.c:23692 [opt]
> >     frame #6: 0x000000010001bf09 emacs`display_mode_line(w=0x000000010482ea30,
> face_id=MODE_LINE_FACE_ID, format=4315887955) at xdisp.c:23211 [opt]
> >     frame #7: 0x000000010004b2e4 emacs`display_mode_lines(w=0x000000010482ea30)
> at xdisp.c:23146 [opt]
> >     frame #8: 0x000000010005180f emacs`redisplay_window(window=4370655797,
> just_this_one_p=<unavailable>) at xdisp.c:17397 [opt]
>
> This just says that Emacs was in redisplay, displaying the mode line
> in some window.
>
> Do you always see this exact backtrace, with the same function calls
> and the same arguments, when you interrupt Emacs that hangs like this?
> Or does the backtrace look different every time?
>
> Thanks.
>



-- 
Sam Steingold <http://sds.podval.org> <http://www.childpsy.net> <
http://steingoldpsychology.com>

[-- Attachment #2: Type: text/html, Size: 12513 bytes --]

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Date: Tue, 22 Aug 2017 14:23:00 -0400
> Cc: 28176@debbugs.gnu.org
> 
> here is the backtrace from an identical hang with a different article in
> the same group:
> 
> 2017-08-22 14:10:48.609113-0400 emacs[16623:7011753] [general] Connection
> to 'pboard' server had an error: <error: 0x7fffb7597ca0> { count = 1,
> transaction: 0, voucher = 0x0, contents =
>         "XPCErrorDescription" => <string: 0x7fffb7597f18> { length = 18,
> contents = "Connection invalid" }
> }
> 2017-08-22 14:11:02.771791-0400 emacs[16623:7011721] Detected potentially
> harmful notification post rate of 229.322 notifications per second
> 2017-08-22 14:11:12.773714-0400 emacs[16623:7011721] Detected potentially
> harmful notification post rate of 300.907 notifications per second
> 2017-08-22 14:11:22.774338-0400 emacs[16623:7011721] Detected potentially
> harmful notification post rate of 280.44 notifications per second
> 2017-08-22 14:11:32.774777-0400 emacs[16623:7011721] Detected potentially
> harmful notification post rate of 290.527 notifications per second
> emacs was compiled with optimization - stepping may behave oddly; variables
> may not be available.
> Process 16623 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
> 
>     frame #0: 0x00000001001a4de9 emacs`lookup_image [inlined]
> search_image_cache(f=0x000000010305afa8, spec=4358862915,
> hash=4195912884339560560) at image.c:1454 [opt]
> 
>    1451
>    1452   for (img = c->buckets[i]; img; img = img->next)
> 
>    1453     if (img->hash == hash
> -> 1454         && !NILP (Fequal (img->spec, spec))
>    1455         && img->frame_foreground == FRAME_FOREGROUND_PIXEL (f)
> 
>    1456         && img->frame_background == FRAME_BACKGROUND_PIXEL (f))
> 
>    1457       break;
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
> 
>   * frame #0: 0x00000001001a4de9 emacs`lookup_image [inlined]
> search_image_cache(f=0x000000010305afa8, spec=4358862915,
> hash=4195912884339560560) at image.c:1454 [opt]
> 
>     frame #1: 0x00000001001a4d82 emacs`lookup_image(f=0x000000010305afa8,
> spec=4358862915) at image.c:1739 [opt]
> 
>     frame #2: 0x0000000100044a68
> emacs`handle_single_display_spec(it=<unavailable>, spec=<unavailable>,
> object=<unavailable>, overlay=<unavailable>, position=<unavailable>,
> bufpos=<unavailable>, display_replaced=<unavailable>,
> frame_window_p=<unavailable>) at xdisp.c:5299 [opt]
> 
>     frame #3: 0x000000010001dd85
> emacs`handle_display_spec(it=0x00007fff5fbf8280, spec=4358862915,
> object=4523100261, overlay=0, position=0x00007fff5fbf83b8, bufpos=1765,
> frame_window_p=<unavailable>) at xdisp.c:4800 [opt]
> 
>     frame #4: 0x00000001000452e1
> emacs`handle_display_prop(it=0x00007fff5fbf8280) at xdisp.c:4719 [opt]
> 
> 
>     frame #5: 0x000000010004544b emacs`handle_stop(it=0x00007fff5fbf8280)
> at xdisp.c:3425 [opt]
>     frame #6: 0x0000000100048434
> emacs`next_element_from_buffer(it=0x00007fff5fbf8280) at xdisp.c:8398 [opt]

This is an entirely different backtrace.

Since you say Emacs is stuck signaling errors, one way to proceed is
to put a breakpoint in xsignal and in Fsignal, and then continue
Emacs.  When it stops at one of these functions, we need to see the
backtrace and maybe examine the error data.

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Sam Steingold]

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

the backtrace _may_ depend on where I happen to hit C-c.

I am prepared to play "remote debugging" if you want to, supplying the
output to the lldb (not gdb!) commands that you will send me.
game?

On Tue, Aug 22, 2017 at 3:10 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Sam Steingold <sds@gnu.org>
> > Date: Tue, 22 Aug 2017 14:23:00 -0400
> > Cc: 28176@debbugs.gnu.org
> >
> > here is the backtrace from an identical hang with a different article in
> > the same group:
> >
> > 2017-08-22 14:10:48.609113-0400 emacs[16623:7011753] [general] Connection
> > to 'pboard' server had an error: <error: 0x7fffb7597ca0> { count = 1,
> > transaction: 0, voucher = 0x0, contents =
> >         "XPCErrorDescription" => <string: 0x7fffb7597f18> { length = 18,
> > contents = "Connection invalid" }
> > }
> > 2017-08-22 14:11:02.771791-0400 emacs[16623:7011721] Detected potentially
> > harmful notification post rate of 229.322 notifications per second
> > 2017-08-22 14:11:12.773714-0400 emacs[16623:7011721] Detected potentially
> > harmful notification post rate of 300.907 notifications per second
> > 2017-08-22 14:11:22.774338-0400 emacs[16623:7011721] Detected potentially
> > harmful notification post rate of 280.44 notifications per second
> > 2017-08-22 14:11:32.774777-0400 emacs[16623:7011721] Detected potentially
> > harmful notification post rate of 290.527 notifications per second
> > emacs was compiled with optimization - stepping may behave oddly;
> variables
> > may not be available.
> > Process 16623 stopped
> > * thread #1, queue = 'com.apple.main-thread', stop reason = signal
> SIGSTOP
> >
> >     frame #0: 0x00000001001a4de9 emacs`lookup_image [inlined]
> > search_image_cache(f=0x000000010305afa8, spec=4358862915,
> > hash=4195912884339560560) at image.c:1454 [opt]
> >
> >    1451
> >    1452   for (img = c->buckets[i]; img; img = img->next)
> >
> >    1453     if (img->hash == hash
> > -> 1454         && !NILP (Fequal (img->spec, spec))
> >    1455         && img->frame_foreground == FRAME_FOREGROUND_PIXEL (f)
> >
> >    1456         && img->frame_background == FRAME_BACKGROUND_PIXEL (f))
> >
> >    1457       break;
> > (lldb) bt
> > * thread #1, queue = 'com.apple.main-thread', stop reason = signal
> SIGSTOP
> >
> >   * frame #0: 0x00000001001a4de9 emacs`lookup_image [inlined]
> > search_image_cache(f=0x000000010305afa8, spec=4358862915,
> > hash=4195912884339560560) at image.c:1454 [opt]
> >
> >     frame #1: 0x00000001001a4d82 emacs`lookup_image(f=
> 0x000000010305afa8,
> > spec=4358862915) at image.c:1739 [opt]
> >
> >     frame #2: 0x0000000100044a68
> > emacs`handle_single_display_spec(it=<unavailable>, spec=<unavailable>,
> > object=<unavailable>, overlay=<unavailable>, position=<unavailable>,
> > bufpos=<unavailable>, display_replaced=<unavailable>,
> > frame_window_p=<unavailable>) at xdisp.c:5299 [opt]
> >
> >     frame #3: 0x000000010001dd85
> > emacs`handle_display_spec(it=0x00007fff5fbf8280, spec=4358862915,
> > object=4523100261, overlay=0, position=0x00007fff5fbf83b8, bufpos=1765,
> > frame_window_p=<unavailable>) at xdisp.c:4800 [opt]
> >
> >     frame #4: 0x00000001000452e1
> > emacs`handle_display_prop(it=0x00007fff5fbf8280) at xdisp.c:4719 [opt]
> >
> >
> >     frame #5: 0x000000010004544b emacs`handle_stop(it=
> 0x00007fff5fbf8280)
> > at xdisp.c:3425 [opt]
> >     frame #6: 0x0000000100048434
> > emacs`next_element_from_buffer(it=0x00007fff5fbf8280) at xdisp.c:8398
> [opt]
>
> This is an entirely different backtrace.
>
> Since you say Emacs is stuck signaling errors, one way to proceed is
> to put a breakpoint in xsignal and in Fsignal, and then continue
> Emacs.  When it stops at one of these functions, we need to see the
> backtrace and maybe examine the error data.
>



-- 
Sam Steingold <http://sds.podval.org> <http://www.childpsy.net> <
http://steingoldpsychology.com>

[-- Attachment #2: Type: text/html, Size: 5653 bytes --]

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[npostavs]

retitle 28176 26.0.50; [macOS] Emacs hangs on entering a specific article in gnus
quit

>> emacs -Q
>> M-x gnus
>> ^ ; gnus-group-enter-server-mode
>> a ; gnus-server-add-server
>> nntp ; method
>> news.gwene.org ; server
>> hit RET on the news.gwene.org line in the server line
>> after a while you get the huge list of newsgroups.
>> search for "stackexchange.history"
>> hit enter, get a list of articles in history.
>> search for "encircled".
>> hit enter, get a hang.
>
> Thanks.  Unfortunately, it doesn't hang for me.
>
>> note that this might be macos-specific ;-(
>
> Maybe it is.  Can someone else reproduce this, on macOS or elsewhere?

Doesn't reproduce on GNU/Linux (both lucid, gtk).  It's probably macOS
specific.

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Date: Tue, 22 Aug 2017 15:18:11 -0400
> Cc: 28176@debbugs.gnu.org
> 
> the backtrace _may_ depend on where I happen to hit C-c.

Yes, I understand.

> I am prepared to play "remote debugging" if you want to, supplying the output to the lldb (not gdb!) commands
> that you will send me.
> game?

Sorry, I don't know lldb well enough to play.  But if you succeed to
hit a breakpoint in Fsignal and we then succeed to understand which
code signals an error and what error, we may be on our way to solve
the problem.

Or are you saying you don't know how to set a breakpoint in a
function?

Thanks.

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Charles A. Roelli]

I can reproduce the issue on macOS 10.6.  After the issue occurs, if I
pause the affected Emacs from GDB, type "b Fsignal", then continue, I
get this:

(gdb) bt
#0  Fsignal (error_symbol=..., data=...) at eval.c:1505
#1  0x0000000100131e4d in xsignal (error_symbol=..., data=...) at lisp.h:3829
#2  0x00000001001fe693 in xsignal1 (error_symbol=..., arg=...) at eval.c:1639
#3  0x00000001001fefd1 in verror (m=0x1003497b0 <tzbuf_format+2840> "Format specifier doesn't match argument type", ap=0x7fff5fbeff90) at eval.c:1824
#4  0x00000001001ff0b0 in error (m=0x1003497b0 <tzbuf_format+2840> "Format specifier doesn't match argument type") at eval.c:1836
#5  0x00000001001f2e4f in styled_format (nargs=3, args=0x7fff5fbf6a00, message=true) at editfns.c:4498
#6  0x00000001001f1ed1 in Fformat_message (nargs=3, args=0x7fff5fbf6a00) at editfns.c:4158
#7  0x000000010004db63 in vadd_to_log (format=0x10036ab40 <__func__.22422+80961> "Unable to set index %d for image %s", ap=0x7fff5fbf6ae0) at xdisp.c:10178
#8  0x000000010004d9f8 in add_to_log (format=0x10036ab40 <__func__.22422+80961> "Unable to set index %d for image %s") at xdisp.c:10162
#9  0x00000001002ee15b in ns_load_image (f=0x1050795a8, img=0x11d3cb560, spec_file=..., spec_data=...) at nsimage.m:111
#10 0x00000001002b5a29 in png_load (f=0x1050795a8, img=0x11d3cb560) at image.c:6279
#11 0x00000001002aff85 in lookup_image (f=0x1050795a8, spec=...) at image.c:1752
#12 0x000000010003c8cc in handle_single_display_spec (it=0x7fff5fbf88a0, spec=..., object=..., overlay=..., position=0x7fff5fbf89d8, bufpos=1289, display_replaced=0, frame_window_p=true) at xdisp.c:5299
#13 0x0000000100039f0d in handle_display_spec (it=0x7fff5fbf88a0, spec=..., object=..., overlay=..., position=0x7fff5fbf89d8, bufpos=1289, frame_window_p=true) at xdisp.c:4800
#14 0x000000010003986e in handle_display_prop (it=0x7fff5fbf88a0) at xdisp.c:4719
#15 0x0000000100035ec9 in handle_stop (it=0x7fff5fbf88a0) at xdisp.c:3425
#16 0x000000010004654a in next_element_from_buffer (it=0x7fff5fbf88a0) at xdisp.c:8398
#17 0x00000001000420c0 in get_next_display_element (it=0x7fff5fbf88a0) at xdisp.c:6992
#18 0x0000000100071f98 in display_line (it=0x7fff5fbf88a0, cursor_vpos=0) at xdisp.c:21318
#19 0x0000000100063f14 in try_window (window=..., pos=..., flags=1) at xdisp.c:17573
#20 0x000000010006136d in redisplay_window (window=..., just_this_one_p=false) at xdisp.c:17020
#21 0x00000001000593ee in redisplay_window_0 (window=...) at xdisp.c:14780
#22 0x00000001001fdcd6 in internal_condition_case_1 (bfun=0x1000593af <redisplay_window_0>, arg=..., handlers=..., hfun=0x100059377 <redisplay_window_error>) at eval.c:1347
#23 0x000000010005934d in redisplay_windows (window=...) at xdisp.c:14760
#24 0x0000000100059308 in redisplay_windows (window=...) at xdisp.c:14754
#25 0x0000000100057c82 in redisplay_internal () at xdisp.c:14249
#26 0x00000001000551e9 in redisplay () at xdisp.c:13469
#27 0x000000010013e30b in read_char (commandflag=1, map=..., prev_event=..., used_mouse_menu=0x7fff5fbff43d, end_time=0x0) at keyboard.c:2484
#28 0x000000010014f217 in read_key_sequence (keybuf=0x7fff5fbff480, bufsize=30, prompt=..., dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9151
#29 0x000000010013a93c in command_loop_1 () at keyboard.c:1372
#30 0x00000001001fdbe6 in internal_condition_case (bfun=0x10013a442 <command_loop_1>, handlers=..., hfun=0x1001398fd <cmd_error>) at eval.c:1323
#31 0x0000000100139fc9 in command_loop_2 (ignore=...) at keyboard.c:1114
#32 0x00000001001fd05f in internal_catch (tag=..., func=0x100139f9c <command_loop_2>, arg=...) at eval.c:1088
#33 0x0000000100139f5a in command_loop () at keyboard.c:1093
#34 0x0000000100139394 in recursive_edit_1 () at keyboard.c:699
#35 0x00000001001395ab in Frecursive_edit () at keyboard.c:770
#36 0x00000001001370c1 in main (argc=2, argv=0x7fff5fbff948) at emacs.c:1706

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

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Sam Steingold]

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

if you use gdb, you can tap into the src/.gdbinit and its "x" and "p"
commands.

[-- Attachment #2: Type: text/html, Size: 561 bytes --]

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Charles A. Roelli]

> From: Sam Steingold <sds@gnu.org>
> Date: Wed, 23 Aug 2017 09:34:53 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, 28176@debbugs.gnu.org,  	Noam Postavsky <npostavs@users.sourceforge.net>
> 
> if you use gdb, you can tap into the src/.gdbinit and its "x" and "p" commands.
> 

Seems like this may be a side effect of a recent change adding GIF
support in macOS (I'm CCing the author, Alan Third).

In nsimage.m:111 (ns_load_image), there is this call to add_to_log:

add_to_log ("Unable to set index %d for image %s", index, img->spec);

but img->spec is a Lisp_Object:

(gdb) ptype img->spec
type = struct Lisp_Object {
    EMACS_INT i;
}

Maybe "%s" doesn't cover Lisp_Objects?  At any rate, that seems to be
what the error message is about.

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Sam Steingold]

> * Eli Zaretskii <ryvm@tah.bet> [2017-08-23 05:27:03 +0300]:
>
> if you succeed to hit a breakpoint in Fsignal and we then succeed to
> understand which code signals an error and what error, we may be on
> our way to solve the problem.

I set the breakpoints using

--8<---------------cut here---------------start------------->8---
(lldb) break set -b Fsignal
Breakpoint 1: where = emacs`Fsignal + 4 at eval.c:1505, address = 0x00000001001370a4
(lldb) break set -b xsignal
Breakpoint 2: where = emacs`xsignal + 4 at lisp.h:3829, address = 0x00000001000b5f54
(lldb) run -Q
--8<---------------cut here---------------end--------------->8---

and got several hits (in require) before I even got the *Scratch* frame.
Then I got a gazillion hits on M-x gnus, so I disabled the breakpoint
and re-enabled it after viewing several articles but before viewing the
bad one (so that everything autoloaded would be loaded before the
error).

here is the backtrace:

--8<---------------cut here---------------start------------->8---
lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x00000001001370a4 emacs`Fsignal(error_symbol=50880, data=4318505459) at eval.c:1505 [opt]
    frame #1: 0x00000001000b5f59 emacs`xsignal(error_symbol=<unavailable>, data=<unavailable>) at lisp.h:3829 [opt]
    frame #2: 0x000000010013561c emacs`xsignal1(error_symbol=<unavailable>, arg=<unavailable>) at eval.c:1639 [opt]
    frame #3: 0x000000010012055a emacs`Fdefault_value(symbol=<unavailable>) at data.c:1645 [opt]
    frame #4: 0x00000001001355e0 emacs`Fdefault_toplevel_value(symbol=10290416) at eval.c:678 [opt]
    frame #5: 0x0000000100139134 emacs`funcall_subr(subr=0x000000010058f200, numargs=1, args=<unavailable>) at eval.c:2832 [opt]
    frame #6: 0x0000000100138630 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2757 [opt]
    frame #7: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=0, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #8: 0x0000000100139611 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=0x00007fff5fbf9900) at eval.c:3040 [opt]
    frame #9: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #10: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=0, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #11: 0x0000000100139611 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=0x00007fff5fbf9bd0) at eval.c:3040 [opt]
    frame #12: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #13: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=0, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #14: 0x0000000100134d2e emacs`eval_sub(form=<unavailable>) at eval.c:2228 [opt]
    frame #15: 0x000000010015b7c5 emacs`readevalloop(readcharfun=24096, infile0=0x00007fff5fbf9f30, sourcename=4529157700, printflag=<unavailable>, unibyte=<unavailable>, readfun=0, start=<unavailable>, end=0) at lread.c:2038 [opt]
    frame #16: 0x0000000100159f60 emacs`Fload(file=<unavailable>, noerror=<unavailable>, nomessage=45456, nosuffix=<unavailable>, must_suffix=4529147476) at lread.c:1432 [opt]
    frame #17: 0x0000000100142f28 emacs`Frequire(feature=237581408, filename=<unavailable>, noerror=<unavailable>) at fns.c:2805 [opt]
    frame #18: 0x0000000100139158 emacs`funcall_subr(subr=0x0000000100590bb0, numargs=1, args=<unavailable>) at eval.c:2837 [opt]
    frame #19: 0x0000000100138630 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2757 [opt]
    frame #20: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=0, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #21: 0x0000000100134d2e emacs`eval_sub(form=<unavailable>) at eval.c:2228 [opt]
    frame #22: 0x000000010015b7c5 emacs`readevalloop(readcharfun=24096, infile0=0x00007fff5fbfa4e0, sourcename=4529146436, printflag=<unavailable>, unibyte=<unavailable>, readfun=0, start=<unavailable>, end=0) at lread.c:2038 [opt]
    frame #23: 0x0000000100159f60 emacs`Fload(file=<unavailable>, noerror=<unavailable>, nomessage=45456, nosuffix=<unavailable>, must_suffix=4529139156) at lread.c:1432 [opt]
    frame #24: 0x0000000100142f28 emacs`Frequire(feature=49488, filename=<unavailable>, noerror=<unavailable>) at fns.c:2805 [opt]
    frame #25: 0x0000000100139158 emacs`funcall_subr(subr=0x0000000100590bb0, numargs=1, args=<unavailable>) at eval.c:2837 [opt]
    frame #26: 0x0000000100138630 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2757 [opt]
    frame #27: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=0, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #28: 0x0000000100134d2e emacs`eval_sub(form=<unavailable>) at eval.c:2228 [opt]
    frame #29: 0x000000010015b7c5 emacs`readevalloop(readcharfun=24096, infile0=0x00007fff5fbfaa90, sourcename=4529044932, printflag=<unavailable>, unibyte=<unavailable>, readfun=0, start=<unavailable>, end=0) at lread.c:2038 [opt]
    frame #30: 0x0000000100159f60 emacs`Fload(file=<unavailable>, noerror=<unavailable>, nomessage=45456, nosuffix=<unavailable>, must_suffix=4523217236) at lread.c:1432 [opt]
    frame #31: 0x00000001001364b5 emacs`Fautoload_do_load(fundef=4297879971, funname=<unavailable>, macro_only=0) at eval.c:2010 [opt]
    frame #32: 0x00000001001384e8 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2774 [opt]
    frame #33: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=2054, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #34: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #35: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=1030, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #36: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #37: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=1030, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #38: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #39: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=1030, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #40: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #41: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=1030, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #42: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #43: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=1030, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #44: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #45: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=1030, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #46: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #47: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=1030, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #48: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #49: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=1030, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #50: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #51: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=1030, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #52: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #53: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=1030, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #54: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #55: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=0, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #56: 0x0000000100139611 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=0x00007fff5fbfc930) at eval.c:3040 [opt]
    frame #57: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #58: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=0, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #59: 0x0000000100139611 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=0x00007fff5fbfcb20) at eval.c:3040 [opt]
    frame #60: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #61: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=0, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #62: 0x0000000100139611 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=0x00007fff5fbfcd00) at eval.c:3040 [opt]
    frame #63: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #64: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=0, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #65: 0x0000000100139611 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=0x00007fff5fbfd010) at eval.c:3040 [opt]
    frame #66: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #67: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=0, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #68: 0x0000000100139611 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=0x00007fff5fbfd480) at eval.c:3040 [opt]
    frame #69: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #70: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=0, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #71: 0x0000000100139611 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=0x00007fff5fbfd6d0) at eval.c:3040 [opt]
    frame #72: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #73: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=0, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #74: 0x0000000100139611 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=0x00007fff5fbfd9b0) at eval.c:3040 [opt]
    frame #75: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #76: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=0, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #77: 0x0000000100139611 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=0x00007fff5fbfdba0) at eval.c:3040 [opt]
    frame #78: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #79: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=0, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #80: 0x0000000100139611 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=0x00007fff5fbfdee0) at eval.c:3040 [opt]
    frame #81: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #82: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=0, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #83: 0x0000000100139611 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=0x00007fff5fbfe120) at eval.c:3040 [opt]
    frame #84: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #85: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=0, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #86: 0x0000000100139611 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=0x00007fff5fbfe3a0) at eval.c:3040 [opt]
    frame #87: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #88: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=0, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #89: 0x0000000100139611 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=0x00007fff5fbfe630) at eval.c:3040 [opt]
    frame #90: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #91: 0x0000000100131f76 emacs`Ffuncall_interactively(nargs=<unavailable>, args=<unavailable>) at callint.c:252 [opt]
    frame #92: 0x0000000100138630 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2757 [opt]
    frame #93: 0x0000000100133559 emacs`Fcall_interactively(function=<unavailable>, record_flag=0, keys=<unavailable>) at callint.c:844 [opt]
    frame #94: 0x0000000100139158 emacs`funcall_subr(subr=0x000000010058ef90, numargs=3, args=<unavailable>) at eval.c:2837 [opt]
    frame #95: 0x0000000100138630 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2757 [opt]
    frame #96: 0x000000010017563a emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=4102, nargs=<unavailable>, args=<unavailable>) at bytecode.c:629 [opt]
    frame #97: 0x00000001001385d1 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2759 [opt]
    frame #98: 0x0000000100138d4c emacs`call1(fn=<unavailable>, arg1=<unavailable>) at eval.c:2608 [opt]
    frame #99: 0x00000001000bbe99 emacs`command_loop_1 at keyboard.c:1486 [opt]
    frame #100: 0x0000000100136e12 emacs`internal_condition_case(bfun=(emacs`command_loop_1 at keyboard.c:1263), handlers=<unavailable>, hfun=(emacs`cmd_error at keyboard.c:942)) at eval.c:1323 [opt]
    frame #101: 0x00000001000ca800 emacs`command_loop_2(ignore=<unavailable>) at keyboard.c:1114 [opt]
    frame #102: 0x00000001001366b9 emacs`internal_catch(tag=<unavailable>, func=(emacs`command_loop_2 at keyboard.c:1110), arg=0) at eval.c:1088 [opt]
    frame #103: 0x00000001000bae5e emacs`command_loop at keyboard.c:1093 [opt]
    frame #104: 0x00000001000bad6f emacs`recursive_edit_1 at keyboard.c:699 [opt]
    frame #105: 0x00000001000bafa3 emacs`Frecursive_edit at keyboard.c:770 [opt]
    frame #106: 0x00000001000b9bb7 emacs`main(argc=0, argv=<unavailable>) at emacs.c:1706 [opt]
    frame #107: 0x00007fffae679235 libdyld.dylib`start + 1
    frame #108: 0x00007fffae679235 libdyld.dylib`start + 1
(lldb) 
--8<---------------cut here---------------end--------------->8---

note that require is _still_ present, but it is probably the actual
suspect - feature 237581408.

I have no idea what to do next.

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://camera.org
http://jij.org http://thereligionofpeace.com http://americancensorship.org
Time would have been the best Teacher, if it did not kill all its students.

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Cc: 28176@debbugs.gnu.org
> Date: Wed, 23 Aug 2017 13:03:12 -0400
> 
> > * Eli Zaretskii <ryvm@tah.bet> [2017-08-23 05:27:03 +0300]:
> >
> > if you succeed to hit a breakpoint in Fsignal and we then succeed to
> > understand which code signals an error and what error, we may be on
> > our way to solve the problem.
> 
> I set the breakpoints using
> 
> --8<---------------cut here---------------start------------->8---
> (lldb) break set -b Fsignal
> Breakpoint 1: where = emacs`Fsignal + 4 at eval.c:1505, address = 0x00000001001370a4
> (lldb) break set -b xsignal
> Breakpoint 2: where = emacs`xsignal + 4 at lisp.h:3829, address = 0x00000001000b5f54
> (lldb) run -Q
> --8<---------------cut here---------------end--------------->8---
> 
> and got several hits (in require) before I even got the *Scratch* frame.
> Then I got a gazillion hits on M-x gnus, so I disabled the breakpoint
> and re-enabled it after viewing several articles but before viewing the
> bad one (so that everything autoloaded would be loaded before the
> error).
> 
> here is the backtrace:

Thanks, but this doesn't look like the error we are looking for: it
doesn't happen in redisplay.  To make more sense of this error, you
need to convert error_symbol and data to human-readable form.  If lldb
doesn't support the scripting in the .gdbinit file, then the only way
is to perform manually what the following commands do:

  xsymbol (for error_symbol)
  xtype (for data)

After we know what is the Lisp type of data, we need to use the
corresponding x* commands to display that type, like xcar and xcdr for
a cons cell.

> note that require is _still_ present, but it is probably the actual
> suspect - feature 237581408.

Why is that suspect?

> I have no idea what to do next.

After we understand this error, and my guess that it is not what we
are looking for is confirmed, the next step is continue the program
and wait for the next time the breakpoint in Fsignal breaks.

Thanks.

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Alan Third]

On Wed, Aug 23, 2017 at 04:29:35PM +0200, Charles A. Roelli wrote:
> Seems like this may be a side effect of a recent change adding GIF
> support in macOS (I'm CCing the author, Alan Third).

I’m quite confused. I tested this against gifs and jpegs, and they
both worked fine. I never tested against pngs as I assumed, being
a single image format like jpeg, it would work the same. It seems that
jpegs are handled differently, though, as I stuck an fprintf in
ns_load_image and it didn’t print anything when I loaded a jpeg.

Anyway, I’ve pushed a modification which fixes pngs while keeping
animated gifs working.

> In nsimage.m:111 (ns_load_image), there is this call to add_to_log:
> 
> add_to_log ("Unable to set index %d for image %s", index, img->spec);
> 
> but img->spec is a Lisp_Object:
> 
> (gdb) ptype img->spec
> type = struct Lisp_Object {
>     EMACS_INT i;
> }
> 
> Maybe "%s" doesn't cover Lisp_Objects?  At any rate, that seems to be
> what the error message is about.

This looks like it’s the same way it’s handled in image.c, so I don’t
know why it doesn’t work here.

Unless it’s actually index that’s at fault since it’s *not* a
Lisp_Object?
-- 
Alan Third

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Charles A. Roelli]

> Date: Wed, 23 Aug 2017 20:10:50 +0100
> From: Alan Third <alan@idiocy.org>
> 
> On Wed, Aug 23, 2017 at 04:29:35PM +0200, Charles A. Roelli wrote:
> > Seems like this may be a side effect of a recent change adding GIF
> > support in macOS (I'm CCing the author, Alan Third).
> 
> I’m quite confused. I tested this against gifs and jpegs, and they
> both worked fine. I never tested against pngs as I assumed, being
> a single image format like jpeg, it would work the same. It seems that
> jpegs are handled differently, though, as I stuck an fprintf in
> ns_load_image and it didn’t print anything when I loaded a jpeg.
> 
> Anyway, I’ve pushed a modification which fixes pngs while keeping
> animated gifs working.

Thanks!
 
> > In nsimage.m:111 (ns_load_image), there is this call to add_to_log:
> > 
> > add_to_log ("Unable to set index %d for image %s", index, img->spec);
> > 
> > but img->spec is a Lisp_Object:
> > 
> > (gdb) ptype img->spec
> > type = struct Lisp_Object {
> >     EMACS_INT i;
> > }
> > 
> > Maybe "%s" doesn't cover Lisp_Objects?  At any rate, that seems to be
> > what the error message is about.
> 
> This looks like it’s the same way it’s handled in image.c, so I don’t
> know why it doesn’t work here.
> 
> Unless it’s actually index that’s at fault since it’s *not* a
> Lisp_Object?

I think you're right.  This prevents the PNG error from causing a
hang for me (adding a call to make_number):

  add_to_log ("Unable to set index %d for image %s", make_number (index), img->spec);

And *Messages* ends up with the right error:

  Unable to set index 0 for image (image :type png :data \211PNG^M...
  (followed by the raw image bytes)

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus

[Alan Third]

On Wed, Aug 23, 2017 at 09:56:15PM +0200, Charles A. Roelli wrote:
> > Unless it’s actually index that’s at fault since it’s *not* a
> > Lisp_Object?
> 
> I think you're right.  This prevents the PNG error from causing a
> hang for me (adding a call to make_number):
> 
>   add_to_log ("Unable to set index %d for image %s", make_number (index), img->spec);
> 
> And *Messages* ends up with the right error:
> 
>   Unable to set index 0 for image (image :type png :data \211PNG^M...
>   (followed by the raw image bytes)

Thanks. Fixed.
-- 
Alan Third