Compiz running on Intel Haswell GPU has 100% CPU usage when computer is locked

I have more information about this bug. It seems like this only happens when Google Chrome is running and it has a tab that's flashing (flashing animation occurs when the tab has a notification, like when Gmail receives a new email or chat). If there is no tab flashing, then CPU usage is normal when screen is locked. The moment a tab starts flashing when the screen is locked, CPU usage skyrockets.

Steps to reproduce:

1.) Launch Google Chrome
2.) Load Gmail in a tab
3.) Lock the screen
4.) SSH into your machine from another machine to look at CPU usage using top.
5.) Send an email to yourself to start tab flashing animation.
6.) See CPU usage of compiz skyrocket in top.
7.) Unlock the screen and see CPU usage of compiz drop.

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

Yep see exactly the same thing here on a Dell Latitude 7440 with Haswell i7 4600U.

As an extra data point, I'm running a newer kernel:
uname -a
Linux e7440 3.15.0-031500rc2-generic #201404201435 SMP Sun Apr 20 18:36:18 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Still seeing this behavior on 15.04 alpha

I can also confirm this behavior on a Lenovo Thinkpad T440s (Haswell Core i7-4600U) with the 15.04 alpha and the default kernel.
I think this should be rated critical because it can cause computers to overheat and cause damage to the hardware.

The problem still occurs in 15.04 with kernel 3.19.0-21 and Compiz :0.9.12.1+15.04.20150410.1-0ubuntu1.

As part of the big bug clear up for 16.04 we have reviewed this bug and we will not be working on it in the near future. Sorry we can't offer you a fix. We will of course review patches if anyone submits them. Please stop by IRC to discuss this option.

I have it too on 15.10 beta, 4.2.0-16-generic, Ivy bridge Intel® Core™ i5-3230M CPU

I faced exaclty the same problem with my system.
I already reported ad bug, now linked to this bug as duplicate.

Again, I confirm (for me):
- When I switch off "screen lock" and wait for screen fades out problem does NOT happen.
- In contrast if I lock screen manually (eg.: Alt-Ctrl-L or xdg-screensaver lock from x-terminal) compiz occupies one core 100%. Due to this fan starts.

I also tested: the https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/969860
but it does not solve my problem, because compiz 100% CPU usage is not linked with power saving of monitor, but lock screen.

My data:
- Fresh install of Ubuntu 15.10 (plus some other non-desktop or gnome related packages)
- All energy consumption related settings are default (I have not changed them till now).
- Laptop: ACER Aspire V3-371
- CPU: Intel Core i5-5257U
- GPU: Intel Iris grapics 6100
- Display: 1920x1080 internal laptop display, no other display ever plugged in.
- 8G RAM
- 120G SSD

Just answering "Benjamin Xiao (ben-r-xiao) wrote on 2014-05-24"-s post.

Unfortunately my problem is much wider.
BTW my processor is in the "Broadwell" family with is the successor or "Haswell" family.

To reproduce my problem:
- Switch on computer.
- log in and lock the screen (Alt+Ctrl+L)
- Press switch to virtual text terminal (eg.: Alt+Ctrl+1)
- use "top" to see what happening.

compiz goes to 100% using one core.
Checking CPU by CPU - hit "1" during running "top":
One core works 30% user 70% system, other 99,9% idle.

It IS very pity that nobody cares this issue, because quite decent systems with the latest Ubuntu is affected.

Till devs do not find a real solution I made a BLOODY BRUTAL workaround which helps me.
PLEASE understand what my program is doing and decide if it is suits you or not.

I found "cpulimit" (can be installed from software center - at least in Ubuntu 15.10) which slows down a particular thread.
No, "nice" does not do the work, because "nice" just gives priorities and here we want that CPUs do not do "anything".

I wrote a small python script which
- checks if screen lock OR screensaver became active, if yes, it limits that thread with "cpulimit"
- checks if screen lock OR screensaver became inactive, if yes, ir removes all limitation

Again, it slows down compiz so violently as possible.
With my system the keyboard lock (Alt-Ctrl-L) fades out for 5-10 secs...
when I enter my password dots has 1 sec lag...

Screensaver part is added to eliminate this lock-screen delay.
Under "normal use" screensaver deactivates earlier, so compiz became much more responsive.

If your programs use compiz during screen lock, it is VERY LIKELY that this script will slow down or somehow affect those programs as well, so use it wisely!

For the script running you have to install python-dbus if you did not do it so far:
sudo apt-get install python-dbus

The python script itself:

#!/usr/bin/env python
import gobject
import dbus
import os
from dbus.mainloop.glib import DBusGMainLoop

def lock_and_screensaver_filter(bus, message):
  EventMember =message.get_member()
  if EventMember == "EventEmitted":
    args = message.get_args_list()
    if args[0] == "desktop-lock":
      os.system("cpulimit -b -P /usr/bin/compiz -l 1")
    elif args[0] == "desktop-unlock":
      os.system("pkill cpulimit")
  elif EventMember == "ActiveChanged":
    args = message.get_args_list()
    if args[0] == True:
      os.system("cpulimit -b -P /usr/bin/compiz -l 1")
    else:
      os.system("pkill cpulimit")

DBusGMainLoop(set_as_default=True)
bus = dbus.SessionBus()
bus.add_match_string("type='signal',interface='com.ubuntu.Upstart0_6'")
bus.add_match_string("type='signal',interface='org.gnome.ScreenSaver'")
bus.add_message_filter(lock_and_screensaver_filter)
mainloop = gobject.MainLoop()
mainloop.run()

The PAM user authenticator in the unity lockscreen busy waits because of a bug in std::future in libstdc++6.

The libstdc++ bug is decribed here, including a patch for fixing it:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68921
(GCC Bugzilla – Bug 68921 [5/6 Regression] std::future::wait() makes invalid futex calls and spins)

strace on compiz while the lockscreen is active shows the following system call being repeated:
futex(0xb32f7a9c, FUTEX_WAIT, -2147483648, {2948397076, 2}) = -1 EINVAL (Invalid argument)

Here is a backtrace of the affected thread in compiz when it is in that syscall:
#0 0xb7795be8 in __kernel_vsyscall ()
#1 0xb74485a7 in syscall () at ../sysdeps/unix/sysv/linux/i386/syscall.S:29
#2 0xb75d8336 in std::__atomic_futex_unsigned_base::_M_futex_wait_until (this=0xb32f7a9c, __addr=0xb32f7a9c, __val=2147483648, __has_timeout=false, __s=...,
    __ns=...) at ../../../../../src/libstdc++-v3/src/c++11/futex.cc:55
#3 0xafa5c04f in std::__atomic_futex_unsigned<2147483648u>::_M_load_and_test_until (__ns=..., __s=..., __has_timeout=<optimized out>, __mo=<optimized out>,
    __equal=<optimized out>, __operand=<optimized out>, __assumed=<optimized out>, this=<optimized out>) at /usr/include/c++/5/bits/atomic_futex.h:104
#4 std::__atomic_futex_unsigned<2147483648u>::_M_load_and_test (__mo=<optimized out>, __equal=<optimized out>, __operand=<optimized out>,
    __assumed=<optimized out>, this=<optimized out>) at /usr/include/c++/5/bits/atomic_futex.h:122
#5 std::__atomic_futex_unsigned<2147483648u>::_M_load_when_equal (__mo=std::memory_order_acquire, __val=1, this=0xb32f7a9c)
    at /usr/include/c++/5/bits/atomic_futex.h:162
#6 std::__future_base::_State_baseV2::wait (this=0xb32f7a94) at /usr/include/c++/5/future:322
#7 std::__basic_future<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::_M_get_result (this=<synthetic pointer>)
    at /usr/include/c++/5/future:681
#8 std::future<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::get (this=<synthetic pointer>)
    at /usr/include/c++/5/future:760
#9 unity::lockscreen::UserAuthenticatorPam::ConversationFunction (num_msg=1, msg=0xa7dba0a8, resp=0xa7dba0a4, appdata_ptr=0xa3c4174)
    at /build/unity-G7ZJ7L/unity-7.3.2+15.10.20151016/lockscreen/UserAuthenticatorPam.cpp:151
#10 0xae996243 in pam_vprompt () from /lib/i386-linux-gnu/libpam.so.0
#11 0xae99640c in pam_prompt () from /lib/i386-linux-gnu/libpam.so.0
#12 0xabd24a7e in ?? () from /lib/i386-linux-gnu/security/pam_unix.so
#13 0xabd22093 in pam_sm_authenticate () from /lib/i386-linux-gnu/security/pam_unix.so
#14 0xae991450 in ?? () from /lib/i386-linux-gnu/libpam.so.0
#15 0xae990c7a in pam_authenticate () from /lib/i386-linux-gnu/libpam.so.0
#16 0xafa5a992 in unity::lockscreen::UserAuthenticatorPam::<lambda(GTask*, gpointer, gpointer, GCancellable*)>::operator() (__closure=0x0, task=0x96c56d0,
    data=0xa3c4174) at /build/unity-G7ZJ7L/unity-7.3.2+15.10.20151016/lockscreen/UserAuthenticatorPam.cpp:55
#17 unity::lockscreen::UserAuthenticatorPam::<lambda(GTask*, gpointer, gpointer, GCancellable*)>::_FUN(GTask *, gpointer, gpointer, GCancellable *) ()
    at /...

I'm running into this problem on Ubuntu 15.10 as well. I originally didn't realize it was the *locked* session that caused difficulties. I just noticed that when my kids logged on, after a half hour the system would power down. This is because compiz at 100%+ CPU heated up the CPU to 114C within that time period. I was tracking lm-sensors output, logs, and finally top, all at the same time, through SSH sessions from another system. I just now determined that it was compiz, only when locked. (btw, media servers with RAID-5 arrays is not the machine you want to hard-power-down repeatedly).

Any hopes for a fix?

Or rather, any hopes to get this libc bug mainlined for 15.10?
or an *actual* workaround (aside from only using KDE)?
This bug is a *big* deal

I have this bug (also as bug 1508219 which is now marked as duplication of this report) on three different machines, each of them were verified via ssh, that indeed, compiz uses 100% CPU when screen is locked. All of them is up-to-date 15.10, one notebook (intel), one desktop (also integrated intel stuff onboard), and one another desktop but with AMD/APU configuration. I also see wild memory leaking like happenings on one of the machines at least (others are not used with long enough uptime to be able to notice, maybe?), eg, according to top, memory usage of compiz starts from something like 4% but it's 14% after three days of being locked, it was also 41% after a week or so once ... And yes, CPU is always at 100% at the momemnt I lock the screen even without power saving of monitor, etc. On all of those machines. Quite annoying, because of fan noise, and especially on the notebook, it's not so great for the battery to have long on battery usage, as you can imagine :(

I also experience this bug, on nVidia (GT220) and 32-bit Ubuntu Wily.

Waiting for gcc 5.4 that will fix the regression, I hope?

I have the same problem on Ubuntu 16.04 LTS xenial, with a Thinkpad T430s.

I have the same issue on Ubuntu 16.04 LTS on Dell Latitude E7440

I'm seeing this with 14.04 and Firefox "Web Content" high cpu use on a:
Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz
Linux 4.4.0-57-generic