Ok reproduced! From the backtrace, I see these 2 threads, the main thread (thread1) owns the threadpool and is waiting for one of these threads to complete. Thread 2 has a QThreadPoolThread which is blocked at QFutureInterfaceBase::waitForResult due to some PAM lightdm stuff.

Thread 2 (Thread 0x7fcd243be700 (LWP 7347)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007fcd6f408b03 in wait (time=18446744073709551615, this=0x7fcd4440a120) at thread/qwaitcondition_unix.cpp:136
#2  QWaitCondition::wait (this=<optimized out>, mutex=0x7fcd444254d8, time=time@entry=18446744073709551615) at thread/qwaitcondition_unix.cpp:208
#3  0x00007fcd6f3fd340 in QFutureInterfaceBase::waitForResult (this=this@entry=0x7fcd243bdae0, resultIndex=resultIndex@entry=0) at thread/qfutureinterface.cpp:313
#4  0x00007fcd39b9cbd2 in result (this=0x7fcd243bdae0) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qfuture.h:171
#5  QLightDM::GreeterImpl::converseWithPam (num_msg=<optimized out>, msg=<optimized out>, resp=0x7fcd243bdb30, appdata_ptr=<optimized out>)
    at /build/buildd/unity8-8.00+14.10.20140811/tests/mocks/LightDM/demo/GreeterPrivate.cpp:153
#6  0x00007fcd3974be40 in pam_vprompt () from /lib/x86_64-linux-gnu/libpam.so.0
#7  0x00007fcd3974c05d in pam_prompt () from /lib/x86_64-linux-gnu/libpam.so.0
#8  0x00007fcd26bd647d in ?? () from /lib/x86_64-linux-gnu/security/pam_unix.so
#9  0x00007fcd26bd34fb in pam_sm_authenticate () from /lib/x86_64-linux-gnu/security/pam_unix.so
#10 0x00007fcd39746dff in ?? () from /lib/x86_64-linux-gnu/libpam.so.0
#11 0x00007fcd3974664d in pam_authenticate () from /lib/x86_64-linux-gnu/libpam.so.0
#12 0x00007fcd39b9a840 in QLightDM::GreeterImpl::authenticateWithPam (pamHandle=0x18bba70) at /build/buildd/unity8-8.00+14.10.20140811/tests/mocks/LightDM/demo/GreeterPrivate.cpp:83
#13 0x00007fcd39b9a950 in runFunctor (this=0x18c0cd0) at /usr/include/x86_64-linux-gnu/qt5/QtConcurrent/qtconcurrentstoredfunctioncall.h:265
#14 QtConcurrent::RunFunctionTask<int>::run (this=0x18c0cd0) at /usr/include/x86_64-linux-gnu/qt5/QtConcurrent/qtconcurrentrunbase.h:104
#15 0x00007fcd6f404ad2 in QThreadPoolThread::run (this=0x1855390) at thread/qthreadpool.cpp:101
#16 0x00007fcd6f407a7f in QThreadPrivate::start (arg=0x1855390) at thread/qthread_unix.cpp:345
#17 0x00007fcd6dc67165 in start_thread (arg=0x7fcd243be700) at pthread_create.c:309
#18 0x00007fcd6eb7b4dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7fcd7128c780 (LWP 7094)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007fcd6f408b03 in wait (time=18446744073709551615, this=0x18c58a0) at thread/qwaitcondition_unix.cpp:136
#2  QWaitCondition::wait (this=this@entry=0x18c6128, mutex=mutex@entry=0x18c6100, time=time@entry=18446744073709551615) at thread/qwaitcondition_unix.cpp:208
#3  0x00007fcd6f403415 in QThreadPoolPrivate::waitForDone (this=this@entry=0x18c6090, msecs=msecs@entry=-1) at thread/qthreadpool.cpp:295
#4  0x00007fcd6f4039f1 in QThreadPool::waitForDone (this=<optimized out>, msecs=msecs@entry=-1) at thread/qthreadpool.cpp:618
#5  0x00007fcd6f62f16d in QCoreApplication::~QCoreApplication (this=0xd79730, __in_chrg=<optimized out>) at kernel/qcoreapplication.cpp:796
#6  0x00007fcd70a75149 in QGuiApplication::~QGuiApplication (this=0xd79730, __in_chrg=<optimized out>) at kernel/qguiapplication.cpp:579
#7  0x0000000000404fb2 in ?? ()
#8  0x00007fcd6eaa1ec5 in __libc_start_main (main=0x404500, argc=1, argv=0x7fff5ce89298, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff5ce89288)
    at libc-start.c:287
#9  0x0000000000405ac9 in _start ()


I'm guessing that the unity8 Greeter is waiting for a password to be entered, but somehow we're skipping this step and unlocking immediately. Then on shutdown, that lock waiting for a password is not released.