From: Simon Pugnet <simon@polaris64.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Po Lu <luangruo@yahoo.com>, 61940@debbugs.gnu.org
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 [thread overview]
Message-ID: <87y1oa2gbb.fsf@polaris64.net> (raw)
In-Reply-To: <837cvu8401.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 17134 bytes --]
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/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]
next prev parent reply other threads:[~2023-03-06 12:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-03 13:08 bug#61940: 29.0.60; Occasional crash when moving point continously with visual line numbers Simon Pugnet
2023-03-03 16:32 ` Eli Zaretskii
2023-03-03 16:38 ` Simon Pugnet
2023-03-03 18:26 ` Eli Zaretskii
2023-03-06 11:53 ` Simon Pugnet
2023-03-06 12:21 ` Eli Zaretskii
2023-03-06 12:43 ` Simon Pugnet [this message]
2023-03-06 13:34 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-06 14:57 ` Simon Pugnet
2023-03-08 14:37 ` Simon Pugnet
2023-03-08 14:59 ` Eli Zaretskii
2023-03-06 13:05 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-06 13:19 ` Simon Pugnet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y1oa2gbb.fsf@polaris64.net \
--to=simon@polaris64.net \
--cc=61940@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=luangruo@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.