Unity freezes when a program uses a lot of CPU and I hover an item on the launcher

Bug #1076393 reported by Davide Depau
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Compiz
New
Undecided
Unassigned
Unity
New
Undecided
Unassigned
compiz (Ubuntu)
Confirmed
Undecided
Unassigned
unity (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

When an application suddenly starts using a lot of CPU (e.g. when I import the favourites with Firefox from a big HTML file), Unity thinks that the program doesn't respond to commands, and the window becomes gray. Though, if I click a button in the window, it works. But if I move the pointer on the launcher while the window is gray, Compiz stops responding, the window becomes unresponsive but there isn't any hard disk activity. I can move the mouse and switch to a TTY. If I run "top" in the tty, I don't see any strange activity. If I kill compiz and start another window manager (like Metacity), I can continue using the program: I'm reporting the bug with Firefox and Metacity...

Another user noticed this behavior, so I made a python script for him to analyze the activity with Unity and KDE while Chrome is starting. Look at the attachments. "Memoria" means "Memory", "Utilizzo CPU" means "CPU usage", "Rete"= Network, Trasmessi=sent, Ricevuti=received, "Variazione dei processi" is the diff between two instances of "ps", "Utilizzo risorse da parte di Compiz" was meant to monitor compiz, but it didn't work.

Tags: quantal
Revision history for this message
Davide Depau (depau) wrote :
Revision history for this message
Davide Depau (depau) wrote :
Mattia Rizzolo (mapreri)
tags: added: quantal
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

From memory, I think the fade plugin is quite inefficient. While it is fading a (unresponsive) window, it continuously generates damage for itself, which will cause high CPU and sluggishness of compiz.

It should not freeze though. That's possibly a different problem.

Changed in compiz (Ubuntu):
status: New → Incomplete
status: Incomplete → New
status: New → Confirmed
Changed in compiz:
status: New → Confirmed
milestone: none → 0.9.9.0
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Oops, I'm describing a possibly different problem. High compiz CPU. Not confirmed :(

Changed in compiz:
status: Confirmed → New
Changed in compiz (Ubuntu):
status: Confirmed → New
Changed in compiz:
milestone: 0.9.9.0 → none
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Do other programs or the launcher respond while the greyed window is not responding? Obviously when a window is greyed it usually means compiz knows the window is not responding.

Changed in compiz:
status: New → Incomplete
Changed in unity:
status: New → Incomplete
Changed in compiz (Ubuntu):
status: New → Incomplete
Changed in unity (Ubuntu):
status: New → Incomplete
Revision history for this message
Davide Depau (depau) wrote :

No, they don't. But I think that, when compiz freezes, they continue responding, but for some reason, compiz (or Xorg, I don't know) doesn't update they're windows. When the windows become gray and Compiz is still responding, the windows respond, but when I hover an item on the launcher, it responds, but immediately compiz freezes and everything stops responding.
But the script that checks memory/CPU usage is run on a terminal: if it really doesn't respond, the process would be frozen too. But it doesn't, so everything is due to compiz, I think...

Sorry if I repeated too many times "but", but I'm not English nor American and I'm still learning it ;)

Changed in compiz:
status: Incomplete → New
Changed in unity:
status: Incomplete → New
Changed in compiz (Ubuntu):
status: Incomplete → New
Changed in unity (Ubuntu):
status: Incomplete → New
Revision history for this message
Davide Depau (depau) wrote :

I had the same issue after quickly closing and reopening laptop's lid, and some times after standby.

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

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

Changed in compiz (Ubuntu):
status: New → Confirmed
Changed in unity (Ubuntu):
status: New → Confirmed
Revision history for this message
rb.eng (rb-engch) wrote :

The description of the bug fits ongoing problems I have experienced in Ubuntu 12.04 for several months.

When several programs are running (Thunderbird, Chromium and evince are frequently used on my system) compiz seems to stop responding. The cursor continues to move with the mouse movement but the rest of the screen is inactive and unresponsive to input. The keyboard is unresponsive except that I can ctrl-Fn to another terminal and pull up sudo top. It seems there is little activity but compiz is active. Nothing seems to be abnormal except the X-window display is unresponsive as described.

My solution has been to kill compiz with signal 3. When returning to the X-window (ctrl-F7 typically) the interface will reset and allow me to continue to work after the screen redraws. Compiz restarts itself and the applications I had open redraw albeit not in the same position or retaining their virtual window space.

 If X-windows becomes unresponsive again (except for the cursor) I can switch to the terminal and kill compiz again. At some point this will fail to work and something about compiz restarting itself seems to fail. Apport never gets involved as there is no crash (I'm not sure how to trigger apport to report the issue).

If this quasi-crash or freeze happening to others it may be unreported and lead to user frustration and abandonment of compiz based interfaces or ubuntu altogether. My suggestion is to formalize the python script suggested by Davideddu.

I have been using this solution over the last 9 to 12 months. In the last week after my latest aptitude upgrade I have had to use this rescue method at typically twice an hour. The latest trigger seems to be when evince (3.4.0-0ubuntu1) is trying to startup or render a pdf.

This problem could use some heat. I'd like to help but am not sure how I can.

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.