bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Sam Steingold
Subject: bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus
Date: Tue, 22 Aug 2017 15:18:11 -0400

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.



--

reply via email to

[Prev in Thread] Current Thread [Next in Thread]