GNU bug report logs - #28176
26.0.50; [macOS] Emacs hangs on entering a specific article in gnus

Previous Next

Full log

View this message in rfc822 format

From: Sam Steingold <sds <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 28176 <at> debbugs.gnu.org
Subject: bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus
Date: Tue, 22 Aug 2017 15:18:11 -0400

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

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 <at> gnu.org> wrote:

> > From: Sam Steingold <sds <at> gnu.org>
> > Date: Tue, 22 Aug 2017 14:23:00 -0400
> > Cc: 28176 <at> 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>

[Message part 2 (text/html, inline)]

Previous Next

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