[Bug 2368622] New: ibus-daemon uses insane amounts of CPU and causes a laggy experience

https://bugzilla.redhat.com/show_bug.cgi?id=2368622

Bug ID: 2368622
           Summary: ibus-daemon uses insane amounts of CPU and causes a
                    laggy experience
           Product: Fedora
           Version: 42
          Hardware: x86_64
                OS: Linux
            Status: NEW
         Component: ibus
          Keywords: Desktop
          Severity: high
          Assignee: [e-mail]
          Reporter: [e-mail]
        QA Contact: [e-mail]
                CC: [e-mail], [e-mail]
  Target Milestone: ---
    Classification: Fedora

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.

[Bug 2368622] ibus-daemon uses insane amounts of CPU and causes a laggy experience

https://bugzilla.redhat.com/show_bug.cgi?id=2368622

--- Comment #1 from fujiwara  ---
(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:
> Boot the system
> Be happy
> 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.

[Bug 2368622] ibus-daemon uses insane amounts of CPU and causes a laggy experience

https://bugzilla.redhat.com/show_bug.cgi?id=2368622

--- Comment #2 from Linus Torvalds  ---
(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

[Bug 2368622] ibus-daemon uses insane amounts of CPU and causes a laggy experience

https://bugzilla.redhat.com/show_bug.cgi?id=2368622

--- Comment #3 from fujiwara  ---
(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.

[Bug 2368622] ibus-daemon uses insane amounts of CPU and causes a laggy experience

https://bugzilla.redhat.com/show_bug.cgi?id=2368622

--- Comment #4 from Linus Torvalds  ---
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.

[Bug 2368622] ibus-daemon uses insane amounts of CPU and causes a laggy experience

https://bugzilla.redhat.com/show_bug.cgi?id=2368622

--- Comment #5 from fujiwara  ---
(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`.

[Bug 2368622] ibus-daemon uses insane amounts of CPU and causes a laggy experience

https://bugzilla.redhat.com/show_bug.cgi?id=2368622

--- Comment #6 from fujiwara  ---
% gdb --pid ${PID}
(gdb) break g_list_concat
(gdb) cont
(gdb) where
(gdb) cont
(gdb) where

[Bug 2368622] ibus-daemon uses insane amounts of CPU and causes a laggy experience

https://bugzilla.redhat.com/show_bug.cgi?id=2368622

--- Comment #7 from Linus Torvalds  ---
(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... ?

[Bug 2368622] ibus-daemon uses insane amounts of CPU and causes a laggy experience

https://bugzilla.redhat.com/show_bug.cgi?id=2368622

--- Comment #8 from fujiwara  ---
(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.

[Bug 2368622] ibus-daemon uses insane amounts of CPU and causes a laggy experience

https://bugzilla.redhat.com/show_bug.cgi?id=2368622

--- Comment #9 from Linus Torvalds  ---
(In reply to fujiwara from comment #8)
> I assume you use the default desktop environment, GNOME Wayland in Fedora 42.

Yes.

[Bug 2368622] ibus-daemon uses insane amounts of CPU and causes a laggy experience

https://bugzilla.redhat.com/show_bug.cgi?id=2368622

--- Comment #10 from Linus Torvalds  ---
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.

[Bug 2368622] ibus-daemon uses insane amounts of CPU and causes a laggy experience

https://bugzilla.redhat.com/show_bug.cgi?id=2368622

--- Comment #11 from fujiwara  ---
(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.

[Bug 2368622] ibus-daemon uses insane amounts of CPU and causes a laggy experience

https://bugzilla.redhat.com/show_bug.cgi?id=2368622

--- Comment #12 from fujiwara  ---
(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.

[Bug 2368622] ibus-daemon uses insane amounts of CPU and causes a laggy experience

https://bugzilla.redhat.com/show_bug.cgi?id=2368622

--- Comment #13 from fujiwara  ---
(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  ---
> % 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.

[Bug 2368622] ibus-daemon uses insane amounts of CPU and causes a laggy experience

https://bugzilla.redhat.com/show_bug.cgi?id=2368622

--- Comment #14 from fujiwara  ---
(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.

[Bug 2368622] ibus-daemon uses insane amounts of CPU and causes a laggy experience

https://bugzilla.redhat.com/show_bug.cgi?id=2368622

--- Comment #15 from fujiwara  ---
I fixed major memory leaks in ibus-1.5.33~rc1-3.fc43 and I'd ask you to test it
if your problem is still observed.

[Bug 2368622] ibus-daemon uses insane amounts of CPU and causes a laggy experience

https://bugzilla.redhat.com/show_bug.cgi?id=2368622

fujiwara  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
   Fixed In Version|                            |ibus-1.5.33~rc2-2.fc43
             Status|NEW                         |ON_QA

[Bug 2368622] ibus-daemon uses insane amounts of CPU and causes a laggy experience

https://bugzilla.redhat.com/show_bug.cgi?id=2368622

Jens Petersen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |needinfo?(torvalds@linux-fo
                   |                            |undation.org)

[Bug 2368622] ibus-daemon uses insane amounts of CPU and causes a laggy experience

https://bugzilla.redhat.com/show_bug.cgi?id=2368622

Linus Torvalds  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|needinfo?(torvalds@linux-fo |
                   |undation.org)               |

--- Comment #16 from Linus Torvalds  ---
Sadly, since F43 is unusable for me for other reasons (kicad not working), I
cannot verify whether the problem seems to have been fixed.