Bug 362589 - After resume from Suspend / Compositing Failure?
Summary: After resume from Suspend / Compositing Failure?
Status: RESOLVED NOT A BUG
Alias: None
Product: plasmashell
Classification: Plasma
Component: general (show other bugs)
Version: 5.5.5
Platform: Kubuntu Linux
: NOR grave
Target Milestone: 1.0
Assignee: David Edmundson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-02 15:40 UTC by PGillespie
Modified: 2017-09-28 14:28 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description PGillespie 2016-05-02 15:40:59 UTC
Based on my discussions reporting Bug 361935, this would appear to be unrelated to:

bug 356394 

or 

Bug 357551

So, I'm filing a new bug as relates to the compositor.

Reproducible: Sometimes

Steps to Reproduce:
1. Suspend
2. Resume
3. After more than one suspend/resume cycle, the compositor fails "almost always".





The compositor's failure is always accompanied by the symptoms described in Bug 357551 (though a bug tracker has never popped up).

"After waking from suspend Plasma is always broken, most commonly the panel and window borders are gone... [and] sometimes I am left with a broken session with no panel, borders, or way to switch windows. Once in a while I get a blank screen and can't even switch to a tty."
Comment 1 Thomas Lübking 2016-05-02 15:52:44 UTC
backtrace or it didn't happen, but it's most likely just bug #341497
Comment 2 PGillespie 2016-05-02 16:18:33 UTC
It's not something I've done before, but I'm just reading about it here:

https://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports

In regards to the problem above, there's no KDE Crash Dialogue. Based on the site above, I would use GDB. Would that be?

gdb plasmashell

If I wanted to trace the error in window borders, panel failure, and compositing errors?
Comment 3 PGillespie 2016-05-02 16:33:59 UTC
I'm sorry, scratch that last question (and you only have to confirm this with me once and we're on our way) . Would plasma-workspace be the component in question?

gdb plasma-workspace
Comment 4 PGillespie 2016-05-02 17:27:14 UTC
Okay. I attached GDB to plasmashell and the appropriate PID. I suspended and resumed twice while GDB was attached. 

The KDE panel locked up after the second suspend. Had to kill GDB and restart plasmashell in order use it. The backtrace follows:

 Thread 16 (Thread 0x7fa84861e700 (LWP 8524)):
#0  0x00007fa857a0ae8d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007fa85bacfc62 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x00007fa85bad18d7 in xcb_wait_for_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x00007fa84a76c629 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#4  0x00007fa85810084e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007fa8571ed6fa in start_thread (arg=0x7fa84861e700) at pthread_create.c:333
#6  0x00007fa857a16b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 15 (Thread 0x7fa845e10700 (LWP 8525)):
#0  0x00007fa857a0ae8d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007fa8547a031c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fa8547a042c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007fa858337a7f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x00007fa8582dedea in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007fa8580fb8a4 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x00007fa85a9a33c5 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#7  0x00007fa85810084e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x00007fa8571ed6fa in start_thread (arg=0x7fa845e10700) at pthread_create.c:333
#9  0x00007fa857a16b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 14 (Thread 0x7fa83664c700 (LWP 8526)):
#0  0x00007fa857a0ae8d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007fa8547a031c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fa8547a042c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007fa858337a7f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x00007fa8582dedea in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007fa8580fb8a4 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x00007fa85a9a33c5 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#7  0x00007fa85810084e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
---Type <return> to continue, or q <return> to quit---
#8  0x00007fa8571ed6fa in start_thread (arg=0x7fa83664c700) at pthread_create.c:333
#9  0x00007fa857a16b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 13 (Thread 0x7fa82ffff700 (LWP 8527)):
#0  0x00007fa857a0ae8d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007fa8547a031c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fa8547a042c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007fa858337a7f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x00007fa8582dedea in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007fa8580fb8a4 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x00007fa85a9a33c5 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#7  0x00007fa85810084e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x00007fa8571ed6fa in start_thread (arg=0x7fa82ffff700) at pthread_create.c:333
#9  0x00007fa857a16b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 12 (Thread 0x7fa82edf6700 (LWP 8528)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007fa85cd48bd4 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Script.so.5
#2  0x00007fa85cd48c19 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Script.so.5
#3  0x00007fa8571ed6fa in start_thread (arg=0x7fa82edf6700) at pthread_create.c:333
#4  0x00007fa857a16b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 11 (Thread 0x7fa79ed45700 (LWP 8532)):
#0  0x00007fa857a0ae8d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007fa8547a031c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fa8547a042c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007fa858337a7f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x00007fa8582dedea in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007fa8580fb8a4 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x00007fa85b329ed6 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#7  0x00007fa85810084e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
Comment 5 David Edmundson 2017-09-28 14:28:23 UTC
That backtrace is missing the first 10 threads; none of the ones listed show a crash.

This is now quite old, and I hope this issue has gone away with newer versions.

Please file a new bug if not.