[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61940: 29.0.60; Occasional crash when moving point continously with
|
From: |
Simon Pugnet |
|
Subject: |
bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers |
|
Date: |
Mon, 06 Mar 2023 12:43:56 +0000 |
Eli Zaretskii <eliz@gnu.org> writes:
From: Simon Pugnet <simon@polaris64.net>
Cc: 61940@debbugs.gnu.org
Date: Mon, 06 Mar 2023 11:53:27 +0000
I managed to trigger this situation again this morning while
working.
Unfortunately I was unable to trigger it while it was being
debugged
in gdb; the problem occurs rarely so it's not easy to reproduce on
demand.
You can simply run Emacs under GDB at all times. As long as Emacs
runs normally, GDB will stay out of the way.
OK, I'm doing that now as we speak.
I think however I've found the culprit: ibus. I noticed that after
this issue occurred and I ended the Emacs process, the compose key
would no longer work in many applications (it still worked in Firefox
however). Also Emacs seemed to be behaving normally again; I wasn't
getting those pauses where keys were getting jumbled any more. I took
a look at the system journal and saw this: -
Mar 06 11:29:46 palenque systemd[1]: Started Process Core Dump (PID
143076/UID 0).
Mar 06 11:29:46 palenque systemd-coredump[143078]: [🡕] Process 1397
(ibus-x11) of user 1000 dumped core.
Stack trace of
thread 1397:
#0
0x00007f8b611bd8ec
n/a (libc.so.6 +
0x878ec)
#1
0x00007f8b6116eea8
raise (libc.so.6 +
0x38ea8)
#2
0x00007f8b6115853d
abort (libc.so.6 +
0x2253d)
#3
0x00007f8b6115929e
n/a (libc.so.6 +
0x2329e)
#4
0x00007f8b611c7657
n/a (libc.so.6 +
0x91657)
#5
0x00007f8b611c9442
n/a (libc.so.6 +
0x93442)
#6
0x00007f8b611cbe63
__libc_free
(libc.so.6 +
0x95e63)
#7
0x00007f8b6135f94e
XFree (libX11.so.6
+ 0x4294e)
#8
0x00005570719e4311
n/a (ibus-x11 +
0xe311)
#9
0x00005570719e619a
n/a (ibus-x11 +
0x1019a)
#10
0x00007f8b61e8159e
n/a (libgdk-3.so.0
+ 0x8b59e)
#11
0x00007f8b61e27029
gdk_display_get_event
(libgdk-3.so.0 +
0x31029)
#12
0x00007f8b61e81a68
n/a (libgdk-3.so.0
+ 0x8ba68)
#13
0x00007f8b614b582b
g_main_context_dispatch
(libglib-2.0.so.0 +
0x5582b)
#14
0x00007f8b6150ccc9
n/a
(libglib-2.0.so.0 +
0xaccc9)
#15
0x00007f8b614b4d8f
g_main_loop_run
(libglib-2.0.so.0 +
0x54d8f)
#16
0x00007f8b61f262b2
ibus_main
(libibus-1.0.so.5 +
0x372b2)
#17
0x00005570719d9505
n/a (ibus-x11 +
0x3505)
#18
0x00007f8b61159790
n/a (libc.so.6 +
0x23790)
#19
0x00007f8b6115984a
__libc_start_main
(libc.so.6 +
0x2384a)
#20
0x00005570719d96f5
n/a (ibus-x11 +
0x36f5)
Stack trace of
thread 1415:
#0
0x00007f8b612309df
__poll (libc.so.6 +
0xfa9df)
#1
0x00007f8b6150cc2f
n/a
(libglib-2.0.so.0 +
0xacc2f)
#2
0x00007f8b614b4d8f
g_main_loop_run
(libglib-2.0.so.0 +
0x54d8f)
#3
0x00007f8b61072aec
n/a
(libgio-2.0.so.0 +
0x10aaec)
#4
0x00007f8b614e2db5
n/a
(libglib-2.0.so.0 +
0x82db5)
#5
0x00007f8b611bbbb5
n/a (libc.so.6 +
0x85bb5)
#6
0x00007f8b6123dd90
n/a (libc.so.6 +
0x107d90)
Stack trace of
thread 1412:
#0
0x00007f8b612309df
__poll (libc.so.6 +
0xfa9df)
#1
0x00007f8b6150cc2f
n/a
(libglib-2.0.so.0 +
0xacc2f)
#2
0x00007f8b614b40e2
g_main_context_iteration
(libglib-2.0.so.0 +
0x540e2)
#3
0x00007f8b614b4132
n/a
(libglib-2.0.so.0 +
0x54132)
#4
0x00007f8b614e2db5
n/a
(libglib-2.0.so.0 +
0x82db5)
#5
0x00007f8b611bbbb5
n/a (libc.so.6 +
0x85bb5)
#6
0x00007f8b6123dd90
n/a (libc.so.6 +
0x107d90)
ELF object binary
architecture: AMD
x86-64
Mar 06 11:29:46 palenque systemd[1]:
systemd-coredump@1-143076-0.service: Deactivated successfully.
I debugged the dumped core and ran "thread apply all bt", this was the
result: -
Thread 3 (Thread 0x7f8b5cfff6c0 (LWP 1412)):
warning: Section `.reg-xstate/1412' in core file too small.
#0 0x00007f8b612309df in __GI___poll (fds=0x557071c51f00, nfds=2,
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x00007f8b6150cc2f in g_main_context_poll (priority=<optimized
out>, n_fds=2, fds=0x557071c51f00, timeout=<optimized out>,
context=0x557071c53eb0) at ../glib/glib/gmain.c:4553
#2 g_main_context_iterate.constprop.0 (context=0x557071c53eb0,
block=1, dispatch=1, self=<optimized out>) at
../glib/glib/gmain.c:4243
#3 0x00007f8b614b40e2 in g_main_context_iteration
(context=0x557071c53eb0, may_block=may_block@entry=1) at
../glib/glib/gmain.c:4313
#4 0x00007f8b614b4132 in glib_worker_main (data=<optimized out>) at
../glib/glib/gmain.c:6416
#5 0x00007f8b614e2db5 in g_thread_proxy (data=0x557071c47b00) at
../glib/glib/gthread.c:831
#6 0x00007f8b611bbbb5 in start_thread (arg=<optimized out>) at
pthread_create.c:444
#7 0x00007f8b6123dd90 in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
Thread 2 (Thread 0x7f8b57fff6c0 (LWP 1415)):
warning: Section `.reg-xstate/1415' in core file too small.
#0 0x00007f8b612309df in __GI___poll (fds=0x557071c646d0, nfds=3,
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x00007f8b6150cc2f in g_main_context_poll (priority=<optimized
out>, n_fds=3, fds=0x557071c646d0, timeout=<optimized out>,
context=0x557071c62bf0) at ../glib/glib/gmain.c:4553
#2 g_main_context_iterate.constprop.0 (context=0x557071c62bf0,
block=1, dispatch=1, self=<optimized out>) at
../glib/glib/gmain.c:4243
#3 0x00007f8b614b4d8f in g_main_loop_run (loop=0x557071c62ce0) at
../glib/glib/gmain.c:4448
#4 0x00007f8b61072aec in gdbus_shared_thread_func
(user_data=0x557071c62bc0) at ../glib/gio/gdbusprivate.c:284
#5 0x00007f8b614e2db5 in g_thread_proxy (data=0x557071c5c640) at
../glib/glib/gthread.c:831
#6 0x00007f8b611bbbb5 in start_thread (arg=<optimized out>) at
pthread_create.c:444
#7 0x00007f8b6123dd90 in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
Thread 1 (Thread 0x7f8b5fd45980 (LWP 1397)):
#0 __pthread_kill_implementation (threadid=<optimized out>,
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007f8b611bd953 in __pthread_kill_internal (signo=6,
threadid=<optimized out>) at pthread_kill.c:78
#2 0x00007f8b6116eea8 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#3 0x00007f8b6115853d in __GI_abort () at abort.c:79
#4 0x00007f8b6115929e in __libc_message (fmt=fmt@entry=0x7f8b612d077e
"%s\n") at ../sysdeps/posix/libc_fatal.c:150
#5 0x00007f8b611c7657 in malloc_printerr
(str=str@entry=0x7f8b612d3590 "double free or corruption (fasttop)")
at malloc.c:5651
#6 0x00007f8b611c9442 in _int_free (av=0x7f8b6130eaa0 <main_arena>,
p=0x557071d50da0, have_lock=have_lock@entry=0) at malloc.c:4525
#7 0x00007f8b611cbe63 in __GI___libc_free
(mem=mem@entry=0x557071d50db0) at malloc.c:3367
#8 0x00007f8b6135f94e in XFree (data=data@entry=0x557071d50db0) at
/usr/src/debug/libx11/libX11-1.8.4/src/XlibInt.c:1633
#9 0x00005570719e4311 in ProcessQueue (connect_id=4,
ims=0x557071e82e50) at ../../util/IMdkit/i18nPtHdr.c:1762
#10 _Xi18nMessageHandler (ims=ims@entry=0x557071e82e50, connect_id=4,
p=p@entry=0x557071db6ab0 ">", delete=delete@entry=0x7ffe74734f84) at
../../util/IMdkit/i18nPtHdr.c:1923
#11 0x00005570719e619a in WaitXIMProtocol (dpy=<optimized out>,
win=<optimized out>, ev=<optimized out>, client_data=0x557071e82e50 "
\t\237qpU") at ../../util/IMdkit/i18nX.c:524
#12 0x00007f8b61e8159e in _gdk_x11_display_queue_events
(display=0x557071bfe0e0) at ../gtk/gdk/x11/gdkeventsource.c:337
#13 0x00007f8b61e27029 in gdk_display_get_event
(display=0x557071bfe0e0) at ../gtk/gdk/gdkdisplay.c:442
#14 0x00007f8b61e81a68 in gdk_event_source_dispatch.lto_priv () at
../gtk/gdk/x11/gdkeventsource.c:354
#15 0x00007f8b614b582b in g_main_dispatch (context=0x557071c27d20) at
../glib/glib/gmain.c:3454
#16 g_main_context_dispatch (context=0x557071c27d20) at
../glib/glib/gmain.c:4172
#17 0x00007f8b6150ccc9 in g_main_context_iterate.constprop.0
(context=0x557071c27d20, block=1, dispatch=1, self=<optimized out>)
at ../glib/glib/gmain.c:4248
#18 0x00007f8b614b4d8f in g_main_loop_run (loop=0x557071d975e0) at
../glib/glib/gmain.c:4448
#19 0x00007f8b61f262b2 in ibus_main () at
/usr/src/debug/ibus/ibus-1.5.28/src/ibusshare.c:327
#20 0x00005570719d9505 in main (argc=<optimized out>, argv=<optimized
out>) at /usr/src/debug/ibus/ibus-1.5.28/client/x11/main.c:1416
So to summarise, I am getting these issues in Emacs while IBus is
being used as my input method. The IBus crash seems to cause Emacs to
hang. Once IBus is no longer running Emacs appears to run normally
again. So it looks like this might be an IBus issue rather than an
Emacs issue, but that's just my best guess from the above.
Kind regards,
--
Simon Pugnet
https://www.polaris64.net/
signature.asc
Description: PGP signature
- bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers, Simon Pugnet, 2023/03/03
- bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers, Eli Zaretskii, 2023/03/03
- bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers, Simon Pugnet, 2023/03/03
- bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers, Eli Zaretskii, 2023/03/03
- bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers, Simon Pugnet, 2023/03/06
- bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers, Eli Zaretskii, 2023/03/06
- bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers,
Simon Pugnet <=
- bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers, Po Lu, 2023/03/06
- bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers, Simon Pugnet, 2023/03/06
- bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers, Simon Pugnet, 2023/03/08
- bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers, Eli Zaretskii, 2023/03/08
- bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers, Po Lu, 2023/03/06
- bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers, Simon Pugnet, 2023/03/06