unity-panel-service consumes 100% of my CPU for 8 seconds to while waiting for a global menu to open

Bug #1227710 reported by Colin Ian King
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
unity (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

When opening a libreoffice calc menu nothing happens for 8 seconds. Using "top" one can observe that unity-panel-service is pegging one of my CPUs at 100%. This is 100% repeatable. Just start libreoffice, open the menu. Opening the menu thereafter is often faster. But from a clean start of libreoffice one can always trigger this issue.

Attached is a video showing the delay in opening a menu. I'm running in a 2.5 Ghz i5 CPU, so 8 seconds equates to 20 billion clock cycles to open a menu.

Revision history for this message
Colin Ian King (colin-king) wrote :
Revision history for this message
Colin Ian King (colin-king) wrote :

Also, unity-panel-service's heap is growing quite rapidly too:

Per Process Memory (K):
  PID Process Type Size RSS PSS
  2776 unity-panel-service Stack 16520 108 108
  2776 unity-panel-service Heap 429272 74504 74504
  2776 unity-panel-service Mapped 503844 259460 250964

Change in memory (K/second):
  PID Process Type Size RSS PSS
  2776 unity-panel-service Mapped 83.60 83.93 83.97 (growing moderately fast)

Is 75.5Mb of heap really required? You could fit a small OS in that :-)

Revision history for this message
Colin Ian King (colin-king) wrote :

Polling system call analysis:
 unity-panel-service (2776), poll:
       2295 immediate timed out calls with zero timeout (non-blocking peeks)
         37 repeated timed out polled calls with non-zero timeouts (light polling)
       1322 repeated immediate timed out polled calls with zero timeouts (heavy polling peeks)
 unity-panel-service (2789), poll:
       2328 immediate timed out calls with zero timeout (non-blocking peeks)
         85 repeated immediate timed out polled calls with zero timeouts (heavy polling peeks)

So it appears that some of the polls() are being called with zero timeout and being called many times, which may explain the CPU pegging at 100%. E.g. spinning in a tight loop on poll().

Revision history for this message
Steve Magoun (smagoun) wrote :

@Colin - I think this is the same issue described in bug 1199877. The LO menus are included in the global menu bar; to achieve this they are treated as indicators. There is a leak somewhere in the indicator-handling code. A workaround is to remove the indicator-appmenu package, which has the side effect of removing the global menu bar functionality.

The u-p-s heap grows apparently unbounded (I've seen it up to 400MB!). GTK maintains a list of signal handlers related to the indicators , and it performs linears searches through that list. It appears that something is not removing handlers from that list. I haven't had time to debug the issue beyond that.

There's a backtrace at https://pastebin.canonical.com/97128/ , and more detail in bug 1199877.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in unity (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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