bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Thread 1 (Thread 0x7f11e55fa2c0 (LWP 35073) "emacs"):
>> #0  0x00007f11e8d139df in poll () at /usr/lib/libc.so.6
>> #1  0x00007f11ec43726b in  () at /usr/lib/libxcb.so.1
>> #2  0x00007f11ec438d1d in xcb_wait_for_event () at 
>>  /usr/lib/libxcb.so.1
>> #3  0x00007f11ec49ab09 in _XReadEvents () at /usr/lib/libX11.so.6
>> #4  0x00007f11ec48143a in XIfEvent () at /usr/lib/libX11.so.6
>> #5  0x00007f11ec4c7f10 in  () at /usr/lib/libX11.so.6
>> #6  0x00007f11ec4bf523 in  () at /usr/lib/libX11.so.6
>> #7  0x00007f11ec4c847c in _XimRead () at /usr/lib/libX11.so.6
>> #8  0x00007f11ec4b8d6c in  () at /usr/lib/libX11.so.6
>> #9  0x00007f11ec4a3c5f in XSetICValues () at /usr/lib/libX11.so.6
>> #10 0x0000563eb62f9d0b in xic_set_preeditarea (w=0x563ec43bdc60, 
>>  x=287, y=493) at xfns.c:3176
>> #11 0x0000563eb62e5194 in handle_one_xevent 
>>  (dpyinfo=dpyinfo@entry=0x563eb8c67800, 
>>  event=event@entry=0x7ffce40dc7e0, finish=finish@entry=0x563eb6994270 
>>  <current_finish>, hold_quit=0x7ffce40dcac0) at xterm.c:20116
>> #12 0x0000563eb62ecec1 in event_handler_gdk (gxev=0x7ffce40dc7e0, 
>>  ev=<optimized out>, data=<optimized out>) at xterm.c:17447
>> #13 0x00007f11ed4d1b0f in  () at /usr/lib/libgdk-3.so.0
>> #14 0x00007f11ed4d96d5 in  () at /usr/lib/libgdk-3.so.0
>> #15 0x00007f11ed47f029 in gdk_display_get_event () at 
>>  /usr/lib/libgdk-3.so.0
>> #16 0x00007f11ed4d9a68 in  () at /usr/lib/libgdk-3.so.0
>> #17 0x00007f11ec60b82b in g_main_context_dispatch () at 
>>  /usr/lib/libglib-2.0.so.0
>> #18 0x00007f11ec662cc9 in  () at /usr/lib/libglib-2.0.so.0
>> #19 0x00007f11ec60a0e2 in g_main_context_iteration () at 
>>  /usr/lib/libglib-2.0.so.0
>> #20 0x00007f11ecdd8eeb in gtk_main_iteration () at 
>>  /usr/lib/libgtk-3.so.0
>> #21 0x0000563eb62d783a in XTread_socket (terminal=<optimized out>, 
>>  hold_quit=0x7ffce40dcac0) at xterm.c:24819
>> #22 0x0000563eb6322f61 in gobble_input () at keyboard.c:7417
>> #23 0x0000563eb6323335 in handle_async_input () at keyboard.c:7648
>> #24 process_pending_signals () at keyboard.c:7662
>> #25 0x0000563eb63ac12d in probably_quit () at eval.c:1661
>> #26 0x0000563eb63c0a50 in maybe_quit () at 
>>  /storage/Work/personal/emacs/src/lisp.h:3689
>
> This again says that Emacs is trying to read input via XIM.  Maybe Po
> Lu could help us understand what could be going on.

Thanks.  Would you please verify that the loop does not involve Emacs
calling xic_set_preeditarea over and over again?  IOW, break on the line
after 3176 in xfns.c, and see if that breakpoint is ever hit?

Otherwise, I suggest looking in your system logs for crashes involving
the input method framework you are using.  Xlib does not know how to
handle IM server crashes, and will either crash trying to access a
nonexistent window or loop waiting for events from the crashed IM
server, which is what I think it's doing here.