GNOME Bugzilla – Bug 711650
bijiben process is spiking a CPU core to 100%
Last modified: 2018-05-04 12:11:03 UTC
I've never used the note application and had to research what this process even was. I kept noticing my fans spinning up when I wasn't doing anything on the system, and top revealed that bijiben-shell-s was spiking a single core to 100% usage. I've never opened this application, and the directory ~/.local/share/bijiben does not exist. Nothing is entered into the syslog regarding this process, and I can't seem to nail down a pattern of when it occurs and for how long it lasts. I just caught it again - I was doing nothing but using Firefox and Empathy, and my fan spun up again. I quickly pulled up a terminal window and ran top to discover bijiben-shell-s was again at 100% and had a time of 1:56.06. It seems to quit at the 2 minute point when it does occur. Since there are no associated logs, how do you want me to go about tracking this one down?
I realized I left out one pertinent detail - I'm running Fedora Core 20 Beta with GNOME 3.10.1.
This is very likely the gnome-shell-provider. Every once some search is done in the shell, this process runs to lookup for existing notes. In the gnome-control-center you should be able to deactivate this behavour if you do not want bijiben process to run. Which does not solve the bug... the shell <-> bijiben communication is dbus. the bijiben activity is happening on tracker side.
It's getting worse. Right now, the computer is doing nothing but serving as a wifi hotspot for my phone. I'm not even using it. Since I can't hear it over the HVAC systems at my office, I didn't notice the fans. I picked it up to check something, and about burnt myself. I checked top, and this is what I found: top - 15:04:31 up 2 days, 16:05, 5 users, load average: 2.04, 2.04, 2.10 Tasks: 369 total, 3 running, 366 sleeping, 0 stopped, 0 zombie %Cpu(s): 26.3 us, 0.1 sy, 0.0 ni, 72.9 id, 0.7 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 24645364 total, 12346728 used, 12298636 free, 432208 buffers KiB Swap: 12273660 total, 0 used, 12273660 free, 7190576 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31304 dan 20 0 368252 10272 7212 R 100.0 0.0 161:26.89 bijiben-shell-s 28542 dan 20 0 368252 10268 7212 R 99.8 0.0 351:06.41 bijiben-shell-s 2852 dan 20 0 2471948 1.065g 52228 S 5.0 4.5 67:01.97 firefox Is there anything you would like me to do to help you troubleshoot this, or should I just deactivate it as you suggested?
Eventually i would appreciate if you run gdb -p 31304 then ask for 'bt' But feel free to kill the unwanted processes and deactivate the feature not to have further annoyance. So, everyone else looking at this report and suffering from the bug : please ping.
Same issue here on my Fedora 20 system. Each time, I do a search in the activity view, I got 18 seconds of 100 CPU usage of /usr/libexec/bijiben-shell-search-provider Installed Packages Name : bijiben Arch : x86_64 Epoch : 0 Version : 3.10.2 Release : 1.fc20 Steps to reproduce: * hit super key and type terminal or any other search term * Now I got up to 18 seconds of 100 CPU load by bijiben-shell-search-provider Over all, I have 2 notes stored in bijiben. Please note, that I don't get a bijing search result in the activity view immediately. To get a result, I have to wait in the activity search until the high CPU load is gone.
This happens after a clean install of F20 Final, when using rpmfusion's akmod-nvidia. It does not happen when using nouveau. Unfortunately, nouveau is totally unusable, due to causing hard lockups every few minutes. My box uses GeForce 6150SE nForce 430 video. The problem happens with either the 3.11 or 3.12 kernel. It did not happen with a fully updated F19. See my comments in https://bugzilla.redhat.com/show_bug.cgi?id=1017978 . I noticed the same 100% CPU usage and the app never appearing when trying to run quadrapassel. Also, openarena doesn't run, though it doesn't cause 100% CPU use - it just messes up my graphics and forces me to log out and back in to straighten it out. None of this breakage happened with F19, and there is no sign the devs are interested in fixing nouveau for GeForce 6 - see https://bugzilla.redhat.com/show_bug.cgi?id=901816 .
Here is the gdb output from bt for running either bijiben or quadrapassel from the command line. They are identical (except for the addresses on the left). I am using akmod-nvidia-304xx corresponding to GeForce 6. (gdb) bt
+ Trace 232995
Andre: thanks for these comments. From your description, it seems you cannot run bijiben. As the initial thread is related to bijiben gnome-shell provider, which is a different executable, you might want to open a distinct report about your issue. There is some debuginfo for nvidia. You could install this, and generate another backtrace to attach to the bug. If you meet this issue with all clutter-gtk applications, eg quadrapassel and totem, you might use this component to report against.
I have exactly the same issue with bijiben-shell-search-provider, which is triggered often when I go to Activities and type several characters and then Enter to start an application. To confirm, the corresponding gdb output is almost identical. Same with totem (which I hadn't tested before).
+ Trace 232996
Andre, sorry about the very late reply. And thanks for the backtrace. It shows nvidia & selinux calls. Did you attach gdb to bijiben or to bijiben-shell-search-provider process?
Trace 232996 is for bijiben-shell-search-provider.
As a workaround, deactivating Bijiben on gnome-control-center Search should fix this issue
*** Bug 738514 has been marked as a duplicate of this bug. ***
I got a different trace: (gdb) bt
+ Trace 234350
Run till exit from #0 0x00007fd6b55b3401 in patternCompare () from /lib64/libsqlite3.so.0 [never finishes] in other words: we're getting stuck inside a sqlite patternCompare() from a call to db_cursor_iter_next() inside biji_get_notes_with_strings().
Bump! Ryan has provided interesting details showing it's really an issue in Bijiben. I've seen a similar behavior on Fedora 21 with version 3.14.2.
Yes thanks Milan. I don't remember exactly what was written, but I might start there (in biji-shell-search-provider.c) biji_get_notes_with_strings (BijibenShellSearchProviderApp *self, gchar **needles) gint parser; GString *match; [...] /* AND is implicit into tracker */ for (parser=0; needles[parser] != NULL; parser++) { match = g_string_append (match, needles[parser]); match = g_string_append (match, "* "); } "match" is the string being built to lookup notes. I'll need to test tracker results from the one hand, compare with in-app search otoh
Thanks for looking at this!
Just for the record: Seeing the same on Arch Linux as well as Debian GNU/Linux Jessie, on amd64.
Still persists on GNOME 3.18.2 (with bijiben 3.18.2).
I can reliably reproduce a high CPU Usage in bijiben 3.14.2 (as provided by Debian 8.7/jessie with the following search string: "30*12*4 + 7200 * 2" I have not been able to get bijiben debug-symbols for the build. I've tried to reproduce this issue with 3.20.2 as provided in Debian 9/stretch which would provide debug symbols, but the issue does not occur there. (But that my be a result of search of bijiben not working at all.) I can provide this stacktrace which includes the stack of most dependencies:
+ Trace 237349
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-notes/issues/18.