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

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

bug#37786: 26.3; Emacs crashes when calling function to decode string


From: Allen Li
Subject: bug#37786: 26.3; Emacs crashes when calling function to decode string
Date: Fri, 18 Oct 2019 18:18:34 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Thu, 17 Oct 2019 21:28:35 -0700, Allen Li <darkfeline@felesatra.moe> 
>>>>>> said:
>
>     Allen> This is the backtrace using the simpler repro from Robert.
>
>     Allen> #0  0x0000000000565ae9 in terminate_due_to_signal (sig=6, 
> backtrace_limit=40) at emacs.c:363
>     Allen> #1  0x000000000058ca83 in emacs_abort () at sysdep.c:2380
>     Allen> #2  0x000000000045c17e in redisplay_internal () at xdisp.c:13797
>     Allen> #3  0x000000000045e0b7 in redisplay_preserve_echo_area 
> (from_where=13) at xdisp.c:14602
>     Allen> #4  0x0000000000667fbe in Fdelete_process (process=XIL(0x6aa3395)) 
> at process.c:1054
>     Allen> #5  0x000000000067716b in kill_buffer_processes (buffer=XIL(0)) at 
> process.c:7819
>     Allen> #6  0x00000000005683d0 in shut_down_emacs (sig=0, stuff=XIL(0)) at 
> emacs.c:2096
>     Allen> #7 0x000000000052d854 in x_connection_closed (dpy=0x2b77f50,
>     Allen> error_message=0x7fffffff6fc0 "X protocol error: BadLength (poly
>     Allen> request too large or internal Xlib length error) on protocol 
> request
>     Allen> 139", ioerror=false) at xterm.c:9799
>
> I thought weʼd fixed these kinds of bugs, but obviously not. Can you
> try your test in combination with the following from etc/DEBUG, it
> should tell us which font is responsible:
>
>     For X protocol errors related to displaying unusual characters or to
>     font-related customizations, try invoking Emacs like this:
>
>       XFT_DEBUG=16 emacs -xrm "emacs.synchronous: true"
>
>     This should produce information from the libXft library which could
>     give useful hints regarding font-related problems in that library.

That gives me the following output:

Loading file /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Regular.otf/0
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-It.otf/0 matches 
new
Loading file /usr/share/fonts/adobe-source-code-pro/SourceCodePro-It.otf/0
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Light.otf/0 
matches new
Loading file /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Light.otf/0
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Bold.otf/0 
matches new
Loading file /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Bold.otf/0
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Regular.otf/0 
matches existing (2)
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Light.otf/0 
matches existing (2)
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Bold.otf/0 
matches existing (2)
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Regular.otf/0 
matches existing (3)
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Light.otf/0 
matches existing (3)
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Bold.otf/0 
matches existing (3)
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Regular.otf/0 
matches existing (4)
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Regular.otf/0 
matches existing (4)
FontFile /usr/share/fonts/noto/NotoColorEmoji.ttf/0 matches new
Loading file /usr/share/fonts/noto/NotoColorEmoji.ttf/0

and then Emacs hangs at this point.

>
> Regards
>
> Robert





reply via email to

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