PCManFM consumes >90% CPU

Thank you for reporting this bug, can you please reproduce this bug with the version on pcmanfm on the precise?

Same happened with me since recently on raring, was ok when installed lxde back on precise, not sure about quantal - was using E

Strace shows flood of

poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5, events=POLLIN|POLLPRI}, {fd=6, events=POLLIN|POLLPRI}, {fd=9, events=0}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN}, {fd=8, events=POLLIN}], 8, 997) = 2 ([{fd=12, revents=POLLHUP}, {fd=14, revents=POLLHUP}])
recvfrom(3, 0xb10cf4, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5, events=POLLIN|POLLPRI}, {fd=6, events=POLLIN|POLLPRI}, {fd=9, events=0}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN}, {fd=8, events=POLLIN}], 8, 996) = 2 ([{fd=12, revents=POLLHUP}, {fd=14, revents=POLLHUP}])
recvfrom(3, 0xb10cf4, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5, events=POLLIN|POLLPRI}, {fd=6, events=POLLIN|POLLPRI}, {fd=9, events=0}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN}, {fd=8, events=POLLIN}], 8, 996) = 2 ([{fd=12, revents=POLLHUP}, {fd=14, revents=POLLHUP}])
recvfrom(3, 0xb10cf4, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)

Here FD 3 is

socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC, 0) = 3
connect(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, 20) = 0
getpeername(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, [20]) = 0
getsockname(3, {sa_family=AF_FILE, NULL}, [2]) = 0
fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0

why does it read 3 if poll returned 12 & 14?

Status changed to 'Confirmed' because the bug affects multiple users.

p.s. maybe it's different issue, since in my case it's 100% reproducible - i.e. pcmanfm always eats 100%cpu (1core). But hung - yes, intermittent, sometimes pcman works (eating 100%) sometimes hangs (with the same dietary)

Same here, 98/99% cpu.
Only with --desktop.
Running pcmanfm with no arguments to get the ui is ok.

I tried removing ~/.config/pcmanfm to let it re-create from scratch but it didn't help.

strace attached (3 seconds then ctrl-c)

Forgot to say this is pcmanfm 1.1.0-0ubuntu2 from Raring.
Precise and Quantal were ok.

bkw@noexcuse:~$ apt-cache policy pcmanfm
pcmanfm:
  Installed: 1.1.0-0ubuntu2
  Candidate: 1.1.0-0ubuntu2
  Version table:
 *** 1.1.0-0ubuntu2 0
        500 http://us.archive.ubuntu.com/ubuntu/ raring/universe i386 Packages

Correction. I just downgraded pcmanfm to 1.0.1-0ubuntu1 from Quantal (rest of machine is still Raring) and it still behaves the same.
Trying Precise next.

Note this install is Raring but updated from Bodhi Linux 2.0 to Precise to Quantal to Raring. There are still Bodhi packages and configs lingering. pcmanfm has been ok until I updated sources.list to Raring though.

Confirmed, downgrading to 0.9.10-0ubuntu2 from Precise works ok.
No other changes (to configs, etc) other than the fact that forcing that version of pcmanfm pulled in some other older versions of other packages.

root@noexcuse:~# apt-cache policy pcmanfm
pcmanfm:
  Installed: 1.0.1-0ubuntu1
  Candidate: 1.1.0-0ubuntu2
  Version table:
     1.1.0-0ubuntu2 0
        500 http://us.archive.ubuntu.com/ubuntu/ raring/universe i386 Packages
     1.1.0-0ubuntu1~precise.1 0
        -10 http://packages.bodhilinux.com/bodhi/ precise/testing i386 Packages
 *** 1.0.1-0ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ quantal/universe i386 Packages
        100 /var/lib/dpkg/status
     0.9.10-0ubuntu2 0
        500 http://archive.ubuntu.com/ubuntu/ precise/universe i386 Packages

root@noexcuse:~# apt-get install pcmanfm=0.9.10-0ubuntu2
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libfm-gtk-bin libfm-gtk3 libfm3
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  libfm-gtk1 libfm1 libmenu-cache1
The following NEW packages will be installed:
  libfm-gtk1 libfm1 libmenu-cache1
The following packages will be DOWNGRADED:
  pcmanfm
0 upgraded, 3 newly installed, 1 downgraded, 0 to remove and 1 not upgraded.
Need to get 51.5 kB/455 kB of archives.
After this operation, 447 kB of additional disk space will be used.
Do you want to continue [Y/n]?

And now "pcmanfm --desktop" uses 0.7% cpu instead of 99%
root@noexcuse:~# ps auxw |grep pcmanfm
bkw 2580 0.7 0.5 84044 10428 pts/3 S+ 14:52 0:00 pcmanfm --desktop

Bear with me through what seems OT...

Well I don't know how this can help, but, the same dist-upgrade from Quantal to Raring also broke lxdm or lxsession for me. lxdm would show the greeter and accept the login info, but then would not launch lxsession, or, maybe it started lxsession but lxsession immediately crashed. In any event, neither lxsession nor any of the things it's autostart file listed were in the process list. But manually running "export DISPLAY=:0 ; lxsession &" from a console screen worked.

I couldn't figure out why lxdm wasn't launching lxsession as it used to before the upgrade, so I uninstalled lxdm and install slim.

slim worked normally, launching my same old lxsession.

And somehow, pcmanfm from raring works too now. No more 100% cpu usage from "pcmanfm --desktop" even though I've upgraded back to the current pcmanfm from raring.

So perhaps the problem is as much lxdm failing to provide something for pcmanfm as it is pcmanfm failing rather ungracefully.

This is saucy salamander amd64 13.10 lubuntu lxde "out of the box". Oh, lubuntu-restricted-extras.

Acer Aspire One D255E Intel Atom dual processor netbook, 1.66 gHz, 20" 1600x900 external monitor, wireless keyboard and mouse, booted off a USB SSD.

Pcmanfm utilization not a problem. Of course this is development and there's always the "dread update". Busiest thing showing on the "top" window is chromium browser. Not my favorite, default font is tiny.

Well lubuntu raring uses lightdm not lxdm, so assuming saucy does too, at least that doesn't conflict with the idea that maybe lxdm was doing or failing to do something. That's really all I changed was installing slim, selecting it as default display manager, uninstall lxdm, reboot.

I've reported the issue to GNOME:
https://bugzilla.gnome.org/show_bug.cgi?id=722692
Let hope they fix it within next few years.

Lubuntu 14.04 LTS after upgrade from 13.10.

pcmanfm consumes 100% CPU after second screen is launched via:

xrandr --output DP3 --off --output DP2 --off --output DP1 --off --output TV1 --off --output HDMI2 --off --output HDMI1 --off --output LVDS1 --mode 1280x800 --pos 0x1024 --rotate normal --output VGA1 --mode 1280x1024 --pos 0x0 --rotate normal

https://bugzilla.gnome.org/show_bug.cgi?id=722692 said the bug is fixed.

I use Lubuntu 14.04, it still has the problem PCManFM consumes >90% CPU.

I had the same problem with Lubuntu 14.04 when I started my computer (a laptop) with a second display.

A workaround is to turn off the second display automatically when the computer starts (in an autostart file in /home/user/.config/lxsession/Lubuntu) - I used xrandr --output VGA1 --off since I was using a vga monitor for my second display.

I then ran a desktop file then calls a bash file (perhaps overkill) that sets xrandr the way I want it.

I think that the key is that you have to get down to one display (your primary display) and then start up the second display. When I do it this way it uses the desktop image file correctly, and my pcmanfm cpu% never goes high.

Phil

I have the same problem in lubutu 14.04. As a workaround if I delete everything on the desktop the problem disappears, but anyone knows about REAL solutions?

Anyone having this problem with just one monitor? I need to try to figure out how to reproduce without a second monitor. I don't have one.

Also looking at that bug report, glib is the culprit. What version do you guys have?

Hi Walter,
I only reproduce the problem with at least 3 monitors and at least one file
on the desktop.
GLIB is 2.19-0ubuntu6 (I'm using lubuntu 14.04). Looks like in lubuntu 14.10
(glibc 2.19-10ubuntu6) I cannot repro the problem.

Best Regards

-----Messaggio originale-----
From: Walter Lapchynski
Sent: Thursday, November 06, 2014 4:14 PM
To: Roberto Beltrami
Subject: [Bug 913273] Re: PCManFM consumes >90% CPU

Anyone having this problem with just one monitor? I need to try to
figure out how to reproduce without a second monitor. I don't have one.

Also looking at that bug report, glib is the culprit. What version do
you guys have?

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/913273

Title:
  PCManFM consumes >90% CPU

Status in GVFS:
  Invalid
Status in “pcmanfm” package in Ubuntu:
  Confirmed

Bug description:
  0. I'm running Lubuntu 11.10.
  1. If I minimise all programs, I don't get to see lubuntu desktop. Instead
it seems that lubuntu desktop sort of hanged.
  2. In 'top' pcmanfm (supposed to be idle) is using over 90% of my CPU.
  3. I have to 'kill -9 PID' to kill pcmanfm.

  Unfortunately, I have no idea about how to reproduce the problem.

  If you need anything else (e.g. logs), tell me.

  ProblemType: Bug
  DistroRelease: Ubuntu 11.10
  Package: pcmanfm 0.9.9-0ubuntu1
  ProcVersionSignature: Ubuntu 3.0.0-14.23-generic 3.0.9
  Uname: Linux 3.0.0-14-generic i686
  ApportVersion: 1.23-0ubuntu4
  Architecture: i386
  Date: Sun Jan 8 02:44:13 2012
  InstallationMedia: Lubuntu 11.10 "Oneiric Ocelot" - Release i386
(20111012)
  Pref_Config_Home_lubuntu:

  ProcEnviron:
   LANGUAGE=en_IN:en
   LANG=en_IN
   SHELL=/bin/bash
  SourcePackage: pcmanfm
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gvfs/+bug/913273/+subscriptions

Software Department
<email address hidden>

-------------------------------------------------------------------------------------------------------------
TESEO spa via Agnelli, 49 63023 FERMO (FM) ITALY
Tel. +39 0734 628818 -- Fax. +39 0734 628816

Disclaimer: This electronic mail transmission may contain legally privileged and/or confidential information. Do not read this if you are not the person(s) named. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you receive this transmission by mistake destroy the original transmission and its attachments without reading or saving in any manner.

Thank you for reporting this bug to Ubuntu.

Ubuntu 20.10 (groovy) reached end-of-life on July 22, 2021.
Ubuntu 19.10 (eoan) reached end-of-life on July 17, 2020.
Ubuntu 19.04 (disco) reached end-of-life on January 23, 2020.
Ubuntu 18.10 (cosmic) reached end-of-life on July 18, 2019.
Ubuntu 17.10 (artful) reached end-of-life on July 19, 2018.
Ubuntu 17.04 (zesty) reached end-of-life on January 13, 2018.
Ubuntu 16.10 (yakkety) reached end-of-life on July 20, 2017.
Ubuntu 16.04 (xenial) reached end-of-life on April 29, 2021.
Ubuntu 15.10 (wily) reached end-of-life on July 28, 2016.
Ubuntu 15.04 (vivid) reached end-of-life on February 4, 2016.
Ubuntu 14.10 (utopic) reached end-of-life on July 23, 2015.
Ubuntu 14.04 (trusty) reached end-of-life on April 25, 2019.
Ubuntu 13.10 (saucy) reached end-of-life on July 17, 2014.
Ubuntu 13.04 (raring) reached end-of-life on January 27, 2014.
Ubuntu 12.10 (quantal) reached end-of-life on May 16, 2014.
Ubuntu 12.04 (precise) reached end-of-life on April 28, 2017.
Ubuntu 11.10 (oneiric) reached end-of-life on May 9, 2013.

See this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We appreciate that this bug may be old and you might not be interested in discussing it any more. But if you are then please upgrade to the latest Ubuntu version and re-test. If you then find the bug is still present in the newer Ubuntu version, please add a comment here telling us which new version it is in.