Not a lot of details here, but I decided that instead of just fixing it with killall ibus-daemon which gets rid of that broken thing, I would at least open a bug report to see if there is some official fix for this. Google shows a lot of people complaining about this going back years, so it's not me. There's no crash, and no obvious system logs either. All I see in system logs is gdm-wayland-session activating, and when I kill it systemd seems to log consumtion information like org.freedesktop.IBus.session.GNOME.service: Consumed 26min 22.196s CPU time, 125.1M memory peak. (That was after the system had been up for one day, so 26 min of CPU time seems pretty excessive) Reproducible: Sometimes Steps to Reproduce: 1. Boot the system 2. Be happy 3. Some time randomly later, notice laggy behavior and ibus-daemon using 100% CPU in top Actual Results: Slow keyboard response on a fast system Expected Results: Snappy action Additional Information: Sorry for the horrible bug report, but can we please just disable ibus-daemon by default as a useless problem-causing thing? When google shows this problem going back AT LEAST to 2020 (and probably longer), with the solution invariably being "kill, restart or disable ibus-daemon to fix the problem temporarily", why is that thing enabled by default in the first place? Please at least give a good setting for this, so that the answer can be for people to not enable that thing. And if somebody has "please debug this next time it happens by doing Xyz", I'll happily do that. But you need to tell me what Xyz is, because I don't know the first thing about ibus-daemon. I know that the "i" is supposed to stand for "intelligent". But honestly, I can come up with a lot better suggestions for what that "i" might stand for. And absolutely *none* of them are polite.
(In reply to Linus Torvalds from comment #0) > which gets rid of that broken thing, I would at least open a bug report to > see if there is some official fix for this. I guess there are any official fixes for your issue but the problem would be case by case. 1. Some cases don't have the certain reproducing steps to be evaluated the issues and it would depend on the hardware specs. 2. Some cases are caused by the applications especially in X11 ones even if ibus-daemon spent the CPU time. 3. Some cases are caused by regression issues with the specific ibus version and some of them were fixed. 4. Some cases are long-standing but expected for about 1 minutes. > org.freedesktop.IBus.session.GNOME.service: Consumed 26min 22.196s CPU > time, 125.1M memory peak. > I need more info to reproduce the issue. I saw the CPU time less than 1 minutes basically. % journalctl | grep "CPU time" | grep org.freedesktop.IBus.session.GNOME.servic ... May 27 00:06:53 requiem-f42 systemd[1754]: org.freedesktop.IBus.session.GNOME.service: Consumed 6.876s CPU time, 96.6M memory peak. May 27 00:07:39 requiem-f42 systemd[1754]: org.freedesktop.IBus.session.GNOME.service: Consumed 6.225s CPU time, 117.1M memory peak. May 27 00:08:04 requiem-f42 systemd[1754]: org.freedesktop.IBus.session.GNOME.service: Consumed 4.827s CPU time, 39.8M memory peak. May 27 01:06:51 requiem-f42 systemd[1754]: org.freedesktop.IBus.session.GNOME.service: Consumed 1min 3.379s CPU time, 264.8M memory peak, 3.7M memory swap peak. May 27 10:52:49 requiem-f42 systemd[1754]: org.freedesktop.IBus.session.GNOME.service: Consumed 37.790s CPU time, 184.7M memory peak, 17.1M memory swap peak. > Reproducible: Sometimes > > Steps to Reproduce: > 1. Boot the system > 2. Be happy > 3. Some time randomly later, notice laggy behavior and ibus-daemon using > 100% CPU in top I cannot reproduce your issue. Probably I'd ask you to run sysprof when you get 100% CPU of ibus-daemon and report the screenshots of the sysprof result and need to know which applications are running with `ps -ef` and `top -b`. > Sorry for the horrible bug report, but can we please just disable > ibus-daemon by default as a useless problem-causing thing? I don't get the root cause of the useless problem. > I know that the "i" is supposed to stand for "intelligent". But honestly, I > can come up with a lot better suggestions for what that "i" might stand for. > And absolutely *none* of them are polite. OK, I'd understand your problem.
(In reply to fujiwara from comment #1) > > I cannot reproduce your issue. Yeah, I'm not at all sure what I do to trigger it either. It does seem to have happened much more the last few months, and one reason *may* be that I've been doing circuit design with kicad. And kicad uses wxWidgets for the GUI side, which is kind of unusual, but is one of the few cross-platform GUI libraries (kicad works on Windows and OSX too). And there does seem to be more than the average number of problem reports of ibus-daemon and wxWidgets. I will see if I can get any debugging out of it the next time it happens. Linus
(In reply to Linus Torvalds from comment #2) > It does seem to have happened much more the last few months, and one reason > *may* be that I've been doing circuit design with kicad. When you get CPU time 100%, please get the logs above. > And kicad uses wxWidgets for the GUI side, which is kind of unusual, but is > one of the few cross-platform GUI libraries (kicad works on Windows and OSX > too). > > And there does seem to be more than the average number of problem reports of > ibus-daemon and wxWidgets. I tried kicad-9.0.2-2.fc42.x86_64 without kicad-packages3d and seems kicad does not support Wayland UI. % env GTK_IM_MODULE=wayland kicad Thread 1 "kicad" received signal SIGSEGV, Segmentation fault. 0x00007ffff3dc5864 in wl_proxy_get_version () from /lib64/libwayland-client.so.0 (gdb) where #0 0x00007ffff3dc5864 in wl_proxy_get_version () at /lib64/libwayland-client.so.0 #1 0x00007ffff5d8588b in wl_display_get_registry (wl_display=0x0) at /usr/include/wayland-client-protocol.h:1108 #2 0x00007ffff5d8769f in gtk_im_context_wayland_global_init (display=0x555555ab9c90) at ../modules/input/imwayland.c:814 #3 0x00007ffff5d87e5b in _gtk_immodule_wayland_init (module=0x555556db4e80) at ../modules/input/imwayland.c:1017 #4 0x00007ffff5a1d3e0 in gtk_im_module_load (module=0x555556db4e80) at ../gtk/gtkimmodule.c:171 #5 0x00007ffff74cce93 in g_type_module_use () at /lib64/libgobject-2.0.so.0 #6 0x00007ffff5a1e1ef in _gtk_im_module_create (context_id=0x555556f55390 "wayland") at ../gtk/gtkimmodule.c:654 #7 0x00007ffff5a1f1c3 in gtk_im_multicontext_get_slave (multicontext=0x555556f3cbc0) at ../gtk/gtkimmulticontext.c:273 #8 0x00007ffff5a1f738 in gtk_im_multicontext_set_use_preedit (context=0x555556f3cbc0, use_preedit=0) at ../gtk/gtkimmulticontext.c:452 #9 0x00007ffff5a19559 in gtk_im_context_set_use_preedit (context=0x555556f3cbc0, use_preedit=0) at ../gtk/gtkimcontext.c:630 #10 0x00007ffff76f1166 in wxWindow::GTKHandleRealized() () at /lib64/libwx_gtk3u_core-3.2.so.0 (gdb) frame 2 #2 0x00007ffff5d8769f in gtk_im_context_wayland_global_init ( display=0x555555ab9c90) at ../modules/input/imwayland.c:814 814 global->registry = wl_display_get_registry (global->display); (gdb) print display $1 = (GdkDisplay *) 0x555555ab9c90 (gdb) print (char*)g_type_name(((GTypeClass *)((GTypeInstance *)display)->g_class)->g_type) $5 = 0x7ffff6fe3e65 "GdkX11Display" Seems kicad use GdkX11Display forcibly in GNOME Wayland. I hardly test kicad every day but one suggestion would be to support Wayland in kicad as wxWidgets 3.2.3 supports Wayland. I tried the wxWidget example code and it works in Wayland. https://github.com/wxWidgets/wxWidgets/blob/master/samples/text/text.cpp # dnf install wxGTK-devel % g++ -o text text.cpp `wx-config --cppflags --libs` % env GTK_IM_MODULE=wayland ./test > I will see if I can get any debugging out of it the next time it happens. Thanks. Please note Google searches are not the official reports for ibus and I appreciate your report.
Well, it happened again, but it calmed down before I got a system trace. I did end up doing 'ltrace' on it, and it was in some loop of constantly doing 3925 g_dbus_message_get_message_type(0x7f75e4cfe980, 0x55c4d13c7c70, 0x7f75e47126a0, 0x7f75e4000040) = 1 3925 g_list_concat(0, 0, 0x7f75e47126a0, 0x7f75e4000040) = 0 [ repeats over and over thousands of times ] but I'm guessing that doesn't really tell you much. Strangely, it didn't seem to do any system calls according to 'strace'. That said, I'm not sure I actually caught the right "now it's really slow" traces.
(In reply to Linus Torvalds from comment #4) > I did end up doing 'ltrace' on it, and it was in some loop of constantly > doing > > 3925 g_dbus_message_get_message_type(0x7f75e4cfe980, 0x55c4d13c7c70, > 0x7f75e47126a0, 0x7f75e4000040) = 1 > 3925 g_list_concat(0, 0, 0x7f75e47126a0, 0x7f75e4000040) = 0 > [ repeats over and over thousands of times ] I think gdb is more useful to get the stack of `g_list_concat()` with installing the glib2-devel-debuginfo and ibus-debuginfo, ibus-gtk3-debuginfo, ibus-libs-debuginfo packages. % gdb --pid ${PID} (gdb) where And the following is what I asked. (In reply to fujiwara from comment #1) > Probably I'd ask you to run sysprof when you get 100% CPU of ibus-daemon and > report the screenshots of the sysprof result and need to know which > applications are running with `ps -ef` and `top -b`. >
% gdb --pid ${PID} (gdb) break g_list_concat (gdb) cont (gdb) where (gdb) cont (gdb) where
(In reply to fujiwara from comment #5) > (In reply to Linus Torvalds from comment #4) > And the following is what I asked. > > (In reply to fujiwara from comment #1) > > Probably I'd ask you to run sysprof when you get 100% CPU of ibus-daemon and Yup. But I had to look up what you asked for, and by the time I had done that, the crazy time was over. It lasted some time (a couple of minutes? It took me a while to react to "now things are slow again"), but it doesn't last forever. And I wasn't running kicad this time around, but I *was* compiling the kernel with "make -j128" like I pretty much always am. And instead of kicad I was using openscad for some enclosure design. and having my web browser with editing emails going on. So there was both lots of CPU load and a fair amount of just various random GUI elements. So I get the feeling that maybe it's some kind of "ibus-daemon falls behind during high load, and then deals very badly with that making the situation even worse". Some quadratic (or worse - exponential?) list manipulation thing that normally isn't a problem with one or two events, but if there's heavy load and there's a few tens or hundreds events queued... ?
(In reply to Linus Torvalds from comment #7) > Yup. But I had to look up what you asked for, and by the time I had done > that, the crazy time was over. OK, thank you. Probably you might need to backup the kind of the instructions to another machine likes your mobile phone not to effect your freeze. I also think you need to install the debuginfo packages above and sysprof package before you reproduce your issue. > And I wasn't running kicad this time around, but I *was* compiling the > kernel with "make -j128" like I pretty much always am. And instead of kicad > I was using openscad for some enclosure design. and having my web browser > with editing emails going on. Reading your issue, the reproducing condition might be to make CPU time 100% at once and the issue might be the CPU time is never recovered. I checked openscad, which is a Qt application but it does not enable Wayland. I.e. after you delete QT_IM_MODULE environment variable, ibus won't be enabled with the application while kwrite works without QT_IM_MODULE in Wayland. > Some quadratic (or worse - exponential?) list manipulation thing that > normally isn't a problem with one or two events, but if there's heavy load > and there's a few tens or hundreds events queued... ? Maybe. using openscad might not be enough to reproduce your issue. I assume you use the default desktop environment, GNOME Wayland in Fedora 42.
(In reply to fujiwara from comment #8) > > I assume you use the default desktop environment, GNOME Wayland in Fedora 42. Yes.
Heh, and to prep for next time, I made sure I had sysprof installed and tried to run it. sysprof dumps core after gathering data, with the system log showing traps: sysprof[985451] trap divide error ip:7f5d5a7c9ec4 sp:7f5ccc774ed8 error:0 in libdex-1.so.1.0.0[10ec4,7f5d5a7b9000+16000] so I'm not entirely convinced I will get any sysprof data if this happens again.
(In reply to fujiwara from comment #8) > I also think you need to install the debuginfo packages above and sysprof > package before you reproduce your issue. + gdb package (In reply to Linus Torvalds from comment #10) > sysprof dumps core after gathering data, with the system log showing OK, I see. I'll file a RFE of the CLI tool for it.
(In reply to fujiwara from comment #11) > (In reply to fujiwara from comment #8) > > I also think you need to install the debuginfo packages above and sysprof > > package before you reproduce your issue. > > + gdb package + sysprof-cli package It can be used easily. % sysprof-cli Ctrl-C % sysprof-cat ./capture.syscap | less Probably I think reporting capture.syscap might be useful. It has --session-bus and --gnome-shell option arguments but I'm not sure about it yet. > > (In reply to Linus Torvalds from comment #10) > > sysprof dumps core after gathering data, with the system log showing > > OK, I see. I'll file a RFE of the CLI tool for it.
(In reply to Linus Torvalds from comment #13) [ Trying to deal with this by email, because now bugzilla doesn't let my log in any more, because it thinks I have too many open sessions. This probably won't work,but maybe the redhat bugzilla has proper email integration ] > > --- Comment #6 from fujiwara <tfujiwar> --- > % gdb --pid ${PID} > (gdb) break g_list_concat > (gdb) cont > (gdb) where > (gdb) cont > (gdb) where Bah, it happened again, and I tried to do this, and that just kills all keyboard input entirely. The mouse still worked, and I got the system back to useable by closing that terminal. And I can do it in a virtual terminal, but that ends up being pretty much completely undebuggable. And sysprof-cat does nothing useful. Possibly due to the floating point exception. Anyway, I was able to get *something* by doing [Wed Jun 11 10:42 ~]$ cat <<EOF | gdb -p 4060 break g_list_concat cont where cont where d breakpoint 1 cont EOF and that results in Thread 1 "ibus-daemon" hit Breakpoint 1, 0x00007fbd8fd28390 in g_list_concat () from /lib64/libglib-2.0.so.0 (gdb) #0 0x00007fbd8fd28390 in g_list_concat () at /lib64/libglib-2.0.so.0 #1 0x000055ee99884213 in bus_dbus_impl_dispatch_message_by_rule_idle_cb () #2 0x00007fbd8fd37e0d in g_idle_dispatch () at /lib64/libglib-2.0.so.0 #3 0x00007fbd8fd31880 in g_main_context_dispatch_unlocked.lto_priv () at /lib64/libglib-2.0.so.0 #4 0x00007fbd8fd3a7a8 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0 #5 0x00007fbd8fd3aa4f in g_main_loop_run () at /lib64/libglib-2.0.so.0 #6 0x000055ee99880f00 in main () (gdb) Continuing. Thread 1 "ibus-daemon" hit Breakpoint 1, 0x00007fbd8fd28390 in g_list_concat () from /lib64/libglib-2.0.so.0 (gdb) #0 0x00007fbd8fd28390 in g_list_concat () at /lib64/libglib-2.0.so.0 #1 0x000055ee99884213 in bus_dbus_impl_dispatch_message_by_rule_idle_cb () #2 0x00007fbd8fd37e0d in g_idle_dispatch () at /lib64/libglib-2.0.so.0 #3 0x00007fbd8fd31880 in g_main_context_dispatch_unlocked.lto_priv () at /lib64/libglib-2.0.so.0 #4 0x00007fbd8fd3a7a8 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0 #5 0x00007fbd8fd3aa4f in g_main_loop_run () at /lib64/libglib-2.0.so.0 #6 0x000055ee99880f00 in main () which doesn't look very promising. That *looks* like a normal main loop. I did it a couple of times, with the same stack trace. Never mind that top still says 4060 torvalds 20 0 656128 76152 6528 R 99.0 0.1 194:40.76 ibus-daemon and the system is still sluggish as a result. So then I ended up killing ibus-daemon again just to have a usable system.
(In reply to Linus Torvalds from comment #13) > Thread 1 "ibus-daemon" hit Breakpoint 1, 0x00007fbd8fd28390 in > g_list_concat () from /lib64/libglib-2.0.so.0 > (gdb) #0 0x00007fbd8fd28390 in g_list_concat () at /lib64/libglib-2.0.so.0 > #1 0x000055ee99884213 in bus_dbus_impl_dispatch_message_by_rule_idle_cb () > #2 0x00007fbd8fd37e0d in g_idle_dispatch () at /lib64/libglib-2.0.so.0 > which doesn't look very promising. That *looks* like a normal main loop. > > I did it a couple of times, with the same stack trace. Great. I need this kind of the stacks but you didn't install ibus-debuginfo but lack more info around `bus_dbus_impl_dispatch_message_by_rule_idle_cb()` as I noted before: (In reply to fujiwara from comment #5) > I think gdb is more useful to get the stack of `g_list_concat()` with > installing the glib2-devel-debuginfo and ibus-debuginfo, > ibus-gtk3-debuginfo, ibus-libs-debuginfo packages. > Now I think the log of D-Bus methods of ibus-daemon with dbus-monitor might be more useful: % ls -l $HOME/.config/ibus/bus/ total 16 -rw-r--r--. 1 fujiwara fujiwara 378 Aug 19 2024 72cb3392b75d44d5b3714c264c3630d0-unix-0 -rw-r--r--. 1 fujiwara fujiwara 382 Nov 22 2021 72cb3392b75d44d5b3714c264c3630d0-unix-1 -rw-r--r--. 1 fujiwara fujiwara 378 Jun 14 23:47 72cb3392b75d44d5b3714c264c3630d0-unix-wayland-0 -rw-rw-r--. 1 fujiwara fujiwara 235 Mar 1 2022 Compose and open the *-unix-wayland-0 file with the latest timestamp while I assume you use the GNOME Wayland desktop. % cat $HOME/.config/ibus/bus/72cb3392b75d44d5b3714c264c3630d0-unix-wayland-0 IBUS_ADDRESS=unix:path=/home/fujiwara/.cache/ibus/dbus-oiLP3dd0,guid=a88a634311fdf3d8eec8c339684d8b7c IBUS_DAEMON_PID=2288 and you can get the log of D-Bus methods when your system has CPU time 100% to check which D-Bus method would have a loop. % ps -ef | grep 2288 fujiwara 2288 2007 0 Jun14 ? 00:00:29 /usr/bin/ibus-daemon --panel disable % dbus-monitor --address unix:path=/home/fujiwara/.cache/ibus/dbus-oiLP3dd0,guid=a88a634311fdf3d8eec8c339684d8b7c > > 4060 torvalds 20 0 656128 76152 6528 R 99.0 0.1 194:40.76 > ibus-daemon > > and the system is still sluggish as a result. Thank you. If you have two laptops and your system can be connected with ssh, I think you can type keys on the remote keyboard more easily.