#72 roccateventhandler uses 100% cpu

[Peter Asplund]

I've noticed that my roccateventhandler process is using 100% cpu, and that there are two of them.
I have a Kone XTD, and the settings and everything is working fine. It is just the high cpu usage that is a problem.

(Nevermind that all cores are running at 100%, I'm compiling lots of stuff in the background as well)

[Peter Asplund]

Oh, I forgot to add: I'm using roccat-tools version 5.1.1 on Gentoo. I will test if an update to 5.4.0 will fix the problem.

[Stefan Achatz]

Closed due to inactivity

[Anonymous]

The update did not fix the problem. Why was the bug closed?

[Peter Asplund]

Here's a screenshot that I just took of the process, using 100%. This is using 5.4.0.

[Stefan Achatz]

I closed this bug report because you didn't tell me if the update fixed this for three weeks.
So, this problem persists. In you first post you have two processes for the same user which should not be possible. In the second screenshot from yesterday it's not visible if there are two processes. The normal way roccateventhandler gets started is via /etc/xdg/autostart/roccateventhandler.desktop. Your first investigation should be why and from where roccateventhandler is started twice.

[Peter Asplund]

Thank you for your answer, I realised when I re-read my report that I had stated that I would test with a newer version. I forgot to provide feedback on that comment.
I'm not at home at the moment, so I will check out the status of how it is currently starting when I get home.

[Peter Asplund]

I'm checking this out now. I still have 2 processes, so that might be the reason for the 100% issue.

[Peter Asplund]

I do have an roccatveenthandler.desktop autostart file in /etc/xdg/autostart/. But I don't know why it starts twice...

[Stefan Achatz]

One thing to test if the double process is the problem:
Do a 'killall roccateventhandler' and restart it from the shell. If all is well, the double start is the problem.
To find out where it's occupied:
Do a debug build of roccat-tools (add -DCMAKE_BUILD_TYPE=Debug in cmake call), connect gdb to the process going bonkers (gdb --pid=PID) and show me a backtrace (bt).

[Peter Asplund]

I've found the answer to the question about several processes listed in htop! Since I only got one process when I ran 'ps aux | grep -i roccateventhandler' I figured there was something wrong with htop, but I didn't really know specifically 'what' that was.
Now I downloaded 5.5.0 release and added the Debug build flag to it, started that, and connected GDB to it. Weirdly enough I now had 4 processes when I checked it with htop!
That got me thinking, and I explored the issue more with ps vs htop, and I tried listing ps with threads, and that was the key. For some reason, htop seems to list all threads!
This is the screenshot when appyling the "tree" setting to htop, so I guess you're running with 4 threads now.
I just started it, and started GDB connected to it, so I will get back to you when it starts consuming 100% CPU.

[Peter Asplund]

After updating to 5.5.0, and building it myself with the Debug flag, I'm yet to see the 100% frenzy. I have GDB attached to it, and monitoring it with htop, so I'll keep my eyes peeled.

[Peter Asplund]

I'm finally seeing the issue again! I've attached to it using GDB (gdb --pid=676).

This is what I'm getting from gdb and backtrace. I tried checking threads and list as well.

peter@skare ~ $ gdb --pid=676
GNU gdb (Gentoo 7.11.1 vanilla) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 676
[New LWP 740]
[New LWP 741]
[New LWP 743]

warning: .dynamic section for "/usr/lib64/libsystemd.so.0" is not at the expected address (wrong library or version mismatch?)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007fdc560fea1d in poll () from /lib64/libc.so.6
(gdb) bt
#0  0x00007fdc560fea1d in poll () from /lib64/libc.so.6
#1  0x00007fdc56402fac in g_main_context_iterate.isra () from /usr/lib64/libglib-2.0.so.0
#2  0x00007fdc56403332 in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0
#3  0x0000000000409dff in main ()
(gdb) list
1   /var/tmp/portage/dev-libs/wayland-1.12.0/work/wayland-1.12.0/src/wayland-server.c: No such file or directory.
(gdb) bt
#0  0x00007fdc560fea1d in poll () from /lib64/libc.so.6
#1  0x00007fdc56402fac in g_main_context_iterate.isra () from /usr/lib64/libglib-2.0.so.0
#2  0x00007fdc56403332 in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0
#3  0x0000000000409dff in main ()
(gdb) thread 
[Current thread is 1 (Thread 0x7fdc578ed980 (LWP 676))]

I hope it gives you some guidance...

[Peter Asplund]

I just wanted to pop by and say that I'm still seeing this issue every day.

I am now using roccat-tools 5.7.0.

[Anonymous]

Hi, I might have found a (quite hacky) fix for the bug maxing out a single CPU core.
For me, it appeared when trying to use the Ryos MK FX on nixos.

When changing any kind of settings via roccatryosmkfxconfig, the whole thing would freeze for a long time, and roccateventhandler would just max out a single core of my CPU. After waiting like half an hour, the setting would actually change - but the event handler would continue to just indefinitely max out the core.

After some digging, I found the culprit:

In 'roccat_window_monitor.c', there lives the following function:

static int error_handler(Display *display, XErrorEvent *event) {
    if (event->error_code == BadWindow)
        return 0;
    return old_error_handler(display, event);
}

using gdb, I found that the program was always stuck at either the line with the if clause, or the line with the return statement.

I then implemented the following trivial (but very ugly) fix:

static int error_handler(Display *display, XErrorEvent *event) {
    if (event->error_code == BadWindow)
        return 0;
//HACK:"if we are in the infinite loop, e.g. the old error handler function pointer is the same as the pointer to this exact function, just abort the error handling and return 0
    if (old_error_handler == &error_handler)
        return 0;
//HACK END
    return old_error_handler(display, event);
}

This fix is quite ugly, and I still don't really understand why the recursing loop even happens in the first place - but it fixes the problem. The driver will not hang anymore, and the ryosmkfxconfig works (mostly, but for the purpose of this post it is fully functional as I would expect). No more hanging and no more wierd maxing out the cpu core.

If anyone is willing to investigate this further, I would be very interested to know what caused the problem in the first place - please update this thread, if you find anything. For now and for me, this journey ends here, as my problem has been solved,

[Stefan Achatz]

Released roccat-tools-5.9.1 which hopefully fixes this along other things.