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

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

bug#30874: 27.0.50; Emacs crashes


From: Robert Pluim
Subject: bug#30874: 27.0.50; Emacs crashes
Date: Mon, 26 Mar 2018 12:33:50 +0200

Jan Synacek <address@hidden> writes:

>>   #19 0x00000000004c2fcb in x_error_handler (display=0x2c59000,
>>   event=0x7fffffff5d40) at xterm.c:9889
>>   #20 0x00007ffff469ce3a in _XError () at /lib64/libX11.so.6
>>   #21 0x00007ffff4699d6b in handle_error () at /lib64/libX11.so.6
>>   ---Type <return> to continue, or q <return> to quit---
>>   #22 0x00007ffff4699e15 in handle_response () at /lib64/libX11.so.6
>>   #23 0x00007ffff469a745 in _XEventsQueued () at /lib64/libX11.so.6
>>   #24 0x00007ffff468c2bd in XPending () at /lib64/libX11.so.6
>>   #25 0x00007ffff64f2c2e in gdk_event_source_prepare () at 
>> /lib64/libgdk-3.so.0
>>   #26 0x00007ffff4e033f9 in g_main_context_prepare () at 
>> /lib64/libglib-2.0.so.0
>>   #27 0x00007ffff4e03dcb in g_main_context_iterate.isra () at
>>   /lib64/libglib-2.0.so.0
>>   #28 0x00007ffff4e03f57 in g_main_context_pending () at 
>> /lib64/libglib-2.0.so.0
>>   #29 0x00007ffff69b2d1d in gtk_events_pending () at /lib64/libgtk-3.so.0
>>   #30 0x00000000004bfee7 in XTread_socket (terminal=<optimized out>,
>>   hold_quit=0x7fffffff6040) at xterm.c:9146
>>   #31 0x00000000004f7301 in gobble_input () at keyboard.c:6890
>>   #32 0x00000000004f7925 in handle_async_input () at keyboard.c:7127
>>   #33 0x00000000004f7925 in process_pending_signals () at keyboard.c:7141
>>   #34 0x00000000005c8e5c in xftfont_open (f=0x13f0c30
>>   <bss_sbrk_buffer+8312368>, entity=0x1243cb5 <bss_sbrk_buffer+6555317>,
>>   pixel_size=15) at xftfont.c:391
>>
>> indicates that the X error message was read when Emacs unblocked input
>> in xftfont_open, and read pending input.  In synchronous X operation,
>> the call to x_error_handler should come from an X function, not from
>> process_pending_signals.  I hoped that seeing the X function that
>> caused the error will allow us to understand better what is causing
>> the problem.  If you still see exactly the same backtrace in
>> synchronous X operation, then I don't see any path forward, except
>> saying that telling Emacs Dejavu Sans Mono can cover the entire
>> Unicode range of characters is not recommended.  (But when I did that
>> with a couple of fonts here, Emacs didn't crash.)  It could be a
>> problem in the font backend you use, or it could be something else.

FWIW, I can reproduce this on Fedora 27 with xterm.c patched to force
synchronous operation. There's no crash, but Emacs hangs, so I sent it
a SIGHUP and got the following:

#0  0x00007ffff048b82d in pthread_cond_wait@@GLIBC_2.3.2 () at 
/lib64/libpthread.so.0
#1  0x00007ffff469dd02 in _XReply (address@hidden, address@hidden, 
address@hidden, address@hidden) at xcb_io.c:590
#2  0x00007ffff469970d in XSync (dpy=0x2c5ba00, address@hidden) at Sync.c:44
#3  0x00007ffff46997ab in _XSyncFunction (dpy=<optimized out>) at Synchro.c:35
#4  0x00007ffff3e17dc8 in XftDrawDestroy (draw=0x3404580) at xftdraw.c:279
#5  0x00000000005c82a9 in xftfont_end_for_frame (f=0x13f2c30 
<bss_sbrk_buffer+8316432>) at xftfont.c:686
#6  0x00000000005781fb in font_update_drivers (address@hidden 
<bss_sbrk_buffer+8316432>, address@hidden(0)) at font.c:3540
#7  0x0000000000428179 in delete_frame (frame=<optimized out>, 
address@hidden(0x98a0)) at frame.c:2013
#8  0x00000000004bf6e3 in x_connection_closed (address@hidden, 
error_message=<optimized out>, 
    address@hidden "X protocol error: BadLength (poly request too large or 
internal Xlib length error) on protocol request 138", address@hidden) at 
xterm.c:9810
#9  0x00000000004c30f0 in x_error_quitter (display=0x2c5ba00, event=<optimized 
out>, event=<optimized out>)
    at xterm.c:9919
#10 0x00000000004c316b in x_error_handler (display=0x2c5ba00, 
event=0x7fffffff3180) at xterm.c:9889
#11 0x00007ffff469fe3a in _XError (address@hidden, address@hidden) at 
XlibInt.c:1434
#12 0x00007ffff469cd6b in handle_error (dpy=0x2c5ba00, err=0x33f8e70, 
in_XReply=<optimized out>) at xcb_io.c:199
#13 0x00007ffff469ce15 in handle_response (dpy=0x2c5ba00, response=0x33f8e70, 
in_XReply=<optimized out>)
    at xcb_io.c:311
#14 0x00007ffff469dd70 in _XReply (address@hidden, address@hidden, 
address@hidden, address@hidden) at xcb_io.c:621
#15 0x00007ffff469970d in XSync (dpy=0x2c5ba00, address@hidden) at Sync.c:44
#16 0x00007ffff46997ab in _XSyncFunction (dpy=<optimized out>) at Synchro.c:35
#17 0x00007ffff4028fe1 in XRenderAddGlyphs (address@hidden, glyphset=<optimized 
out>, address@hidden, address@hidden, address@hidden, address@hidden "", 
nbyte_images=<optimized out>) at Glyph.c:112
#18 0x00007ffff3e1c7ef in XftFontLoadGlyphs (address@hidden, address@hidden, 
address@hidden, glyphs=<optimized out>, address@hidden, nglyph=<optimized out>) 
at xftglyphs.c:694
#19 0x00007ffff3e1943b in XftGlyphExtents (address@hidden, address@hidden, 
address@hidden, address@hidden, address@hidden) at xftextent.c:53
#20 0x00007ffff3e195ca in XftTextExtents8 (address@hidden, address@hidden, 
address@hidden <ascii_printable+1> 
"!\"#$%&'()*+,-./0123456789:;<=>address@hidden|}~", address@hidden, 
address@hidden) at xftextent.c:139
#21 0x00000000005c9247 in xftfont_open (f=0x13f2c30 <bss_sbrk_buffer+8316432>, 
entity=XIL(0x1459ea5), pixel_size=27)
    at xftfont.c:378
#22 0x000000000057a9bc in font_open_entity (f=0x13f2c30 
<bss_sbrk_buffer+8316432>, entity=XIL(0x1459ea5), pixel_size=27) at font.c:2903
#23 0x00000000005cb134 in fontset_find_font (address@hidden(0x1466c35), 
address@hidden, address@hidden, address@hidden, address@hidden) at fontset.c:707
#24 0x00000000005cb94b in fontset_font (address@hidden(0x1466c35), 
address@hidden, address@hidden, id=-1) at fontset.c:788
#25 0x00000000005cbc4c in face_for_char (f=0x13f2c30 <bss_sbrk_buffer+8316432>, 
address@hidden, c=10060, pos=<optimized out>, object=<optimized out>) at 
fontset.c:990
#26 0x0000000000447639 in FACE_FOR_CHAR (object=<optimized out>, pos=<optimized 
out>, character=<optimized out>, face=0x2d4a720, f=<optimized out>) at 
dispextern.h:1818
#27 0x0000000000447639 in get_next_display_element (address@hidden) at 
xdisp.c:7324
#28 0x000000000044e758 in display_line (address@hidden, address@hidden) at 
xdisp.c:21502
#29 0x000000000045389d in try_window (address@hidden(0x13f3c35), pos=..., 
address@hidden)
    at xdisp.c:17718
#30 0x00000000004668f1 in redisplay_window (window=XIL(0x13f3c35), 
address@hidden)
    at xdisp.c:17165
#31 0x000000000046948b in redisplay_window_0 (address@hidden(0x13f3c35)) at 
xdisp.c:14922
#32 0x0000000000561f46 in internal_condition_case_1 (address@hidden 
<redisplay_window_0>, address@hidden(0x13f3c35), handlers=<optimized out>, 
address@hidden <redisplay_window_error>) at eval.c:1356
#33 0x0000000000434475 in redisplay_windows (window=XIL(0x13f3c35)) at 
xdisp.c:14902
#34 0x00000000004571fd in redisplay_internal () at xdisp.c:14385
#35 0x0000000000458ef5 in redisplay () at xdisp.c:13597
#36 0x00000000004fa5bb in read_char (address@hidden, address@hidden(0x34aa213), 
prev_event=XIL(0), address@hidden, address@hidden) at keyboard.c:2486
#37 0x00000000004fd0fb in read_key_sequence (address@hidden, address@hidden(0), 
address@hidden, address@hidden, address@hidden, address@hidden, bufsize=30) at 
keyboard.c:9137
#38 0x00000000004febee in command_loop_1 () at keyboard.c:1370
#39 0x0000000000561eae in internal_condition_case (address@hidden 
<command_loop_1>, address@hidden(0x5280), address@hidden <cmd_error>) at 
eval.c:1332
#40 0x00000000004f0a3c in command_loop_2 (address@hidden(0)) at keyboard.c:1111
#41 0x0000000000561e1d in internal_catch (address@hidden(0xc750), 
address@hidden <command_loop_2>, address@hidden(0)) at eval.c:1097
#42 0x00000000004f09e4 in command_loop () at keyboard.c:1090
#43 0x00000000004f5843 in recursive_edit_1 () at keyboard.c:696
#44 0x00000000004f5b57 in Frecursive_edit () at keyboard.c:767
#45 0x000000000041a840 in main (argc=2, argv=0x7fffffffdcf8) at emacs.c:1724

Robert





reply via email to

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