Bug 1017978

Summary: bijiben and bijiben-shell-search-provider HIGH CPU usage
Product: [Fedora] Fedora Reporter: Asif Ali Rizvan <fast.rizwaan>
Component: bijibenAssignee: Pete Walter <walter.pete>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 23CC: bbbush.yuan, bitlord0xff, i, josian2200, mailingdotlist, mailings, maksim.v.zubkov, metherid, optyler, py, robatino, scorpy_sk, snark2004-first, stefan.home
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-12-20 12:42:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
top showing 99-100% usage of bijiben none

Description Asif Ali Rizvan 2013-10-10 21:49:28 UTC
Description of problem:

bijiben and/or

bijiben shell search plugin in fedora 21 (rawhide) is causing high cpu usage.

Version-Release number of selected component (if applicable):


How reproducible:
on fedora 21 always 

Steps to Reproduce:
1. run bijiben from terminal 
2. watch cpu usage going up and the app won't launch
3. kill -KILL bijiben
4. watch cpu usage going down

Actual results:
cpu usage rises
bijiben doesn't startup

Expected results:
bijiben should start and cpu usage be normal

Additional info:
nvidia akmods, fedora 21 (nodebug kernel 3.12-rc4)

Comment 1 Asif Ali Rizvan 2013-10-10 21:51:30 UTC
Created attachment 810815 [details]
top showing 99-100% usage of bijiben

Comment 2 Pierre-Yves Luyten 2013-10-11 09:06:27 UTC
Did bijiben run properly before? Do you have a lot of bijiben notes (or, maybe, gnote or tomboy notes if you use the lastest version of bijiben?)

You can run from the commande line
G_MESSAGES_DEBUG=all bijiben

This might provide a bit more info.

Comment 3 Asif Ali Rizvan 2013-10-11 12:49:57 UTC
I downgraded the kernel from 3.12-rc4 to 3.11-301, now bijiben is working fine. Also nouveau crashes in 3.12-rc kernels.

closing, as bijiben is not responsible. thanks.

Comment 4 Andre Robatino 2014-01-02 19:07:30 UTC
I am seeing something very similar in F20. Frequently, when I go into and then return from Activities, I see bijiben-shell using near 100% CPU, and I have to kill it (the default -TERM works). I can also start either bijiben or quadrapassel from the terminal, and in either case CPU goes up to near 100% and the app doesn't launch (I haven't tried other apps, but there are probably more). I am also using akmod-nvidia (since nouveau causes frequent lockups on my machine). Fully updated including the 3.12 kernel, but I believe the problem also happened with the 3.11 release kernel.

Comment 5 Andre Robatino 2014-01-02 19:12:24 UTC
Sorry, I was probably seeing "bijiben-shell-search-provider", not "bijiben-shell", since only the former exists on my machine, and the name is truncated by top.

Comment 6 Andre Robatino 2014-01-03 01:10:20 UTC
If I switch from nvidia to nouveau, then I can bring up quadrapassel normally, and the bijiben problem doesn't seem to happen either. Unfortunately, since this machine is not usable with nouveau (see https://bugzilla.redhat.com/show_bug.cgi?id=901816 ), it's not an option.

Comment 7 Pierre-Yves Luyten 2014-01-03 10:26:39 UTC
Concerning the nvidia issue: quadrapassel also uses clutter-gtk. Concerning the provider (gnome shell search) : adding upstream bug report.

Comment 8 Branko Grubić 2014-01-04 10:14:00 UTC
I have the same problem, saw it today first time ('bijiben-shell-search-provider'), I aslo have nvidia graphics card, but I'm using 'nouveau' driver.
There was a similar bug with 'nautilus' shell search feature (probably not related) ( https://bugzilla.gnome.org/show_bug.cgi?id=710413 ) 

01:00.0 VGA compatible controller: NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] (rev a1)


'quadrapassel' works here

Comment 9 Andre Robatino 2014-01-04 18:52:06 UTC
(In reply to (bitlord) from comment #8)
> I have the same problem, saw it today first time
> ('bijiben-shell-search-provider'), I aslo have nvidia graphics card, but I'm
> using 'nouveau' driver.
> There was a similar bug with 'nautilus' shell search feature (probably not
> related) ( https://bugzilla.gnome.org/show_bug.cgi?id=710413 ) 
> 
> 01:00.0 VGA compatible controller: NVIDIA Corporation G98 [GeForce 8400 GS
> Rev. 2] (rev a1)
> 
> 
> 'quadrapassel' works here

You might want to look at the GNOME bug referred to in comment 7 ( http://bugzilla.gnome.org/show_bug.cgi?id=711650 ). Does totem (another clutter-gtk app) work? For me it behaves the same as quadrapassel and bijiben*. Your gdb output would probably be more useful in the GNOME bug as well, since it doesn't involve nvidia.

Comment 10 Andre Robatino 2014-01-04 19:50:10 UTC
@bitlord: Also, do you only see the problem intermittently? If so, you might have to run apps like quadrapassel, bijiben and totem repeatedly to see if it happens with the same frequency as bijiben-shell-search-provider. For me, the gdb trace seemed to indicate that they were all the same issue. (But then, I'm using nvidia.)

Comment 11 Andre Robatino 2014-03-07 02:37:47 UTC
For what it's worth, I can run both bijiben and quadrapassel when running live from Fedora-Live-Desktop-x86_64-rawhide-20140305.iso, with clutter-gtk-1.5.2-2.fc21.x86_64. So hopefully this will work in F21.

Comment 12 Maksim Zubkov 2014-06-05 15:58:38 UTC
Same issue.

bijiben-shell-search-provider cause high cpu usage.

I have nvidia graphic card with nouveau driver.

kernel.x86_64                      3.14.4-200.fc20
bijiben.x86_64                       3.10.2-1.fc20

Totem and other clutter app work fine.

gnome-session 3.10.1

Iostat shows that bijiben-shell-search-provider take ~99% io.

Comment 13 Štefan Gurský 2014-06-09 01:19:42 UTC
Similar (or probably same problem) here. bijiben shell search provider takes about 99% of CPU when typing in acrivities overview (and a few seconds after). I do not know if it is related to graphics card. I have some intel card:

$ lspci| grep -i vga
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)

Comment 14 Pierre-Yves Luyten 2014-06-09 22:35:18 UTC
Unfortunately I still cannot reproduce this issue, a profiling would be very useful here

Comment 15 Ferreira Patrick 2015-04-22 09:42:14 UTC
I got the same issue

▸ uname -a
Linux pfa-fedora-qwam 3.19.3-200.fc21.x86_64 #1 SMP Thu Mar 26 21:39:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
▸ lspci| grep -i vga
01:00.0 VGA compatible controller: NVIDIA Corporation G86 [GeForce 8500 GT] (rev a1)
▸ gnome-shell --version
GNOME Shell 3.14.4

Maybe you'll find something relevent here : 

▸ G_MESSAGES_DEBUG=all bijiben
(bijiben:22751): Gtk-DEBUG: Connecting to session manager
** (bijiben:22751): DEBUG: IMPORT to local
** (bijiben:22751): DEBUG: IMPORT to local
** (bijiben:22751): WARNING **: Enumerator failed : Aucun fichier ou dossier de ce type
(bijiben:22751): GLib-GIO-CRITICAL **: g_file_enumerator_close_async: assertion 'G_IS_FILE_ENUMERATOR (enumerator)' failed
** (bijiben:22751): WARNING **: Enumerator failed : Aucun fichier ou dossier de ce type
(bijiben:22751): GLib-GIO-CRITICAL **: g_file_enumerator_close_async: assertion 'G_IS_FILE_ENUMERATOR (enumerator)' failed
(bijiben:22751): dconf-WARNING **: failed to commit changes to dconf: Le délai d'attente est dépassé
** (bijiben:22751): DEBUG: manager: notify changed, 1
Unable to load location /home/pferreira/.local/share/bijiben/.Trash: Aucun fichier ou dossier de ce type** (bijiben:22751): DEBUG: manager: notify changed, 1
(bijiben:22751): GLib-GObject-WARNING **: invalid (NULL) pointer instance
(bijiben:22751): GLib-GObject-CRITICAL **: g_signal_handler_disconnect: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
(bijiben:22751): GLib-GObject-WARNING **: invalid (NULL) pointer instance
(bijiben:22751): GLib-GObject-CRITICAL **: g_signal_handler_disconnect: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
(bijiben:22751): GLib-GObject-WARNING **: invalid (NULL) pointer instance
(bijiben:22751): GLib-GObject-CRITICAL **: g_signal_handler_disconnect: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

Comment 16 Ferry Huberts 2015-05-12 10:05:29 UTC
I have this on an up-to-date F21, please bump version.
Happen when I return from the activities view.
It consumes 100% of 1 CPU for about a minute most of the time, sometimes much more than that (and this is on a fast machine with a fast SSD).

Comment 17 snark2004-first 2015-06-01 12:56:10 UTC
And F22 - fedup'd yesterday from F20. Never saw the issue on F20.

Never used it, didn't know I had it till now. I have chmod'd it a-x.

Comment 18 Jan Kurik 2015-07-15 14:44:55 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Comment 19 José Antonio 2015-08-22 14:49:56 UTC
I'm experiencing this bug with Fedora 22, though deactivating Gnome Notes as a source for the Gnome Shell searches seems to solve the issue. Wouldn't be better to have it disabled by default if it causes so much cpu usage?

By the way the high CPU usage remains for a period of like 30-40 seconds after the search is finished, after that the cpu usage drops, but seems rather odd that the others search sources don't seem to cause so much distress on the cpu.

Comment 20 Fedora Admin XMLRPC Client 2016-11-17 21:46:19 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 21 Fedora Admin XMLRPC Client 2016-11-17 22:41:40 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 22 Fedora End Of Life 2016-11-24 11:03:07 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 23 Fedora End Of Life 2016-12-20 12:42:20 UTC
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.