trash bin uses excessive CPU resources when full

Bug #1241338 reported by Jeffrey Newbro on 2013-10-18
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Cairo-Dock Plug-ins
Undecided
Unassigned
gvfs
New
Undecided
Unassigned

Bug Description

I just upgraded to 3.3.1 and found that my CPU got heavily loaded as soon as anything was put in the trash bin. Disabling the bin applet resolved the problem.

Fabounet (fabounet03) on 2013-10-18
affects: cairo-dock-plug-ins → gvfs
affects: gvfs → cairo-dock-plug-ins
Fabounet (fabounet03) wrote :

Hi,
this is a known issue with gvfsd-trash.
This may be linked to this bug-report: https://bugzilla.gnome.org/show_bug.cgi?id=587221

can you try to reproduce the bug, then kill the process gvfsd-trash, see if it spawns agains, and then if the CPU load is lower ?

Jeffrey Newbro (in-da-chipz) wrote :

Hi,

Thank you for your interest in this problem and although I am having difficulty reproducing the problem, I wanted to tell you as much as I could about it in case the information is of any use to you. The computer on which I had the problem is quite similar to the one in the bug-report you linked below (It's a Dell D-630 laptop), and I just did the version upgrade from Ubuntu 13.04 to 13.10 when the problem appeared. I think that the version upgrade also upgraded Cairo-dock, but I'm not absolutely sure of that.

As I said earlier, whenever I put anything in the trash bin, I would get very high CPU usage until I exited Cairo-dock. Then, when I removed the bin from Cairo-dock, the problem stopped. Today, at your suggestion, I put the bin back in Cairo-dock, but I am unable to reproduce the problem. There are 9 gvfsd-trash processes when I log in, and the number increases with each deposit into the trash bin, but does not diminish when I empty the bin. I killed all the gvfsd-trash processes and they did not re-spawn. Without those processes running, I put a file in the trash and was unable either to empty or restore the file (the buttons on the trash bin window were grayed out as if it was already empty).

That's about all I know at the moment, but I will continue to try to reproduce the problem and send you the results of the test you suggested. If there is anything else you would like me to do when the problem arises again, please let me know. In the meanwhile, I wish you the best of luck in solving this and thank you for your time and attention.

Have a great day.

Hi,
thanks for all these infos

"There are 9 gvfsd-trash processes when I log in, and the number increases
with each deposit into the trash bin, but does not diminish when I empty
the bin"
I think this is clearly not an expected behavior.
9 gvfsd-trash processes seems already a lot (do you have 9 partitions ?)
but it probably shouldn't increase.
Hopefully they will fix it :-)

2013/10/18 Jeffrey Newbro <email address hidden>

> Hi,
>
> Thank you for your interest in this problem and although I am having
> difficulty reproducing the problem, I wanted to tell you as much as I
> could about it in case the information is of any use to you. The
> computer on which I had the problem is quite similar to the one in the
> bug-report you linked below (It's a Dell D-630 laptop), and I just did
> the version upgrade from Ubuntu 13.04 to 13.10 when the problem
> appeared. I think that the version upgrade also upgraded Cairo-dock, but
> I'm not absolutely sure of that.
>
> As I said earlier, whenever I put anything in the trash bin, I would get
> very high CPU usage until I exited Cairo-dock. Then, when I removed the
> bin from Cairo-dock, the problem stopped. Today, at your suggestion, I
> put the bin back in Cairo-dock, but I am unable to reproduce the
> problem. There are 9 gvfsd-trash processes when I log in, and the number
> increases with each deposit into the trash bin, but does not diminish
> when I empty the bin. I killed all the gvfsd-trash processes and they
> did not re-spawn. Without those processes running, I put a file in the
> trash and was unable either to empty or restore the file (the buttons on
> the trash bin window were grayed out as if it was already empty).
>
> That's about all I know at the moment, but I will continue to try to
> reproduce the problem and send you the results of the test you
> suggested. If there is anything else you would like me to do when the
> problem arises again, please let me know. In the meanwhile, I wish you
> the best of luck in solving this and thank you for your time and
> attention.
>
> Have a great day.
>
> --
> You received this bug notification because you are a member of Cairo-
> Dock Devs, which is subscribed to Cairo-Dock Plug-ins.
> https://bugs.launchpad.net/bugs/1241338
>
> Title:
> trash bin uses excessive CPU resources when full
>
> Status in Cairo-Dock: Plug-ins:
> New
> Status in GVFS:
> New
>
> Bug description:
> I just upgraded to 3.3.1 and found that my CPU got heavily loaded as
> soon as anything was put in the trash bin. Disabling the bin applet
> resolved the problem.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cairo-dock-plug-ins/+bug/1241338/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~cairo-dock-team
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~cairo-dock-team
> More help : https://help.launchpad.net/ListHelp
>

Jeffrey Newbro (in-da-chipz) wrote :

Hi,

Happy to help.

I have 4 ext4 partitions not including the swap one, but I do notice that "df" lists 10 filesystems, which may account for the large number of gvfs-trash processes. The extras are mounted at /dev and /run/[something]. None of those are listed in fstab, of course, but they may be provided with a gvfs-trash anyway. I don't really know.

Anyway, I have still been unable to reproduce the bug, which suggests to me that it may be a timing problem that has been mitigated by caching that has become more efficient during the course of using the system. Bear in mind that it only surfaced shortly after a system upgrade. In any case, I'm sure the developers will figure it out, and I thank you again for your interest in the problem.

In the meanwhile, have a good day :-).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.