Bug 407221 - Random KWin hang on VirtualDesktop RefCount
Summary: Random KWin hang on VirtualDesktop RefCount
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (other bugs)
Version First Reported In: git master
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-04 16:46 UTC by Roman Gilg
Modified: 2022-01-19 15:34 UTC (History)
3 users (show)

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

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Gilg 2019-05-04 16:46:39 UTC 
I have KWin hangs rather often in the last few weeks. KWin just does not react anymore, but does not segfault. Last backtrace in frozen state gives me this:



Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007feebac30932 in QtPrivate::RefCount::ref (this=0x0) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:54
54          inline bool ref() Q_DECL_NOTHROW {
(gdb) bt
#0  0x00007feebac30932 in QtPrivate::RefCount::ref() (this=0x0) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:54
#1  0x00007feebac4df03 in QVector<KWin::VirtualDesktop*>::QVector(QVector<KWin::VirtualDesktop*> const&) (this=0x7ffec8307cd0, v=...) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qvector.h:359
#2  0x00007feebaefc980 in KWin::Options::glPlatformInterface() const (this=0x7ffec8307cd0) at /home/roman/dev/kde/build/kde/workspace/kwin/kwin_autogen/EWIEGA46WW/../../../../../../src/kde/workspace/kwin/options.h:600
#3  0x00007feebac3292e in KWin::Toplevel::isOnAllDesktops() const (this=0x556355875d00) at /home/roman/dev/kde/src/kde/workspace/kwin/toplevel.h:837
#4  0x00007feebac32a5f in KWin::Toplevel::isOnDesktop(int) const (this=0x556355875d00, d=1) at /home/roman/dev/kde/src/kde/workspace/kwin/toplevel.h:853
#5  0x00007feebacfdb16 in KWin::Placement::placeAtRandom(KWin::AbstractClient*, QRect const&, KWin::Placement::Policy) (this=0xd0bc2af7f5e1fc00, c=0x556355ecd240, area=...) at /home/roman/dev/kde/src/kde/workspace/kwin/placement.cpp:165
#6  0x00007feebacfde09 in KWin::Placement::placeSmart(KWin::AbstractClient*, QRect const&, KWin::Placement::Policy) (this=0x556355ecd5f0, c=0x5563569da950, area=...) at /home/roman/dev/kde/src/kde/workspace/kwin/placement.cpp:234
#7  0x00007feebacfd561 in KWin::Placement::place(KWin::AbstractClient*, QRect&, KWin::Placement::Policy, KWin::Placement::Policy) (this=0x556355ecd5f0, c=0x5563569da950, area=..., policy=KWin::Placement::Smart, nextPlacement=KWin::Placement::Unknown)
    at /home/roman/dev/kde/src/kde/workspace/kwin/placement.cpp:94
#8  0x00007feebacfd3a6 in KWin::Placement::place(KWin::AbstractClient*, QRect&) (this=0x556355ecd5f0, c=0x5563569da950, area=...) at /home/roman/dev/kde/src/kde/workspace/kwin/placement.cpp:74
#9  0x00007feebae4d549 in KWin::ShellClient::doMinimize() (this=0x556355af22c0) at /home/roman/dev/kde/src/kde/workspace/kwin/shell_client.cpp:1775
#10 0x00007feebae46aed in KWin::ShellClient::init() (this=0x5563569da950) at /home/roman/dev/kde/src/kde/workspace/kwin/shell_client.cpp:369
#11 0x00007feebae59aa6 in QTypedArrayData<KWayland::Server::OutputInterface*>::iterator::operator+(int) const (this=0x7ffec8308080, j=0) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qarraydata.h:160
#12 0x00007feebae58da9 in QVector<KWayland::Server::OutputInterface*>::reallocData(int, int, QFlags<QArrayData::AllocationOption>) (this=0x7feeb849dc60, asize=21859, aalloc=1435093824, options=...) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qvector.h
#13 0x00007feebae57c00 in QtPrivate::SequentialContainerConverterHelper<KWayland::Server::ServerSideDecorationManagerInterface::Mode, false>::registerConverter(int) () at /usr/include/x86_64-linux-gnu/qt5/QtCore/qmetatype.h:1543
#14 0x00007ffec8308120 in  ()
#15 0x0000000000000000 in  ()
Comment 1 Roman Gilg 2019-05-05 18:12:27 UTC 
Just experienced it again. But it's not really a freeze, seems more to be an endless loop (kwin_wayalnd with 100% cpu load) in the placement routine when opening a new window.
Comment 2 Vlad Zahorodnii 2019-05-06 07:52:01 UTC 
What's the latest commit in your local master?
Comment 3 Roman Gilg 2019-05-12 09:32:59 UTC 
Don't know what it was back then. Let's wait for it happening again or for someone else and otherwise close the report.
Comment 4 David Gow 2019-05-26 19:54:14 UTC 
I'm getting similar, frequent hangs with the kubuntu beta PPA (which claims to be KWin 5.15.90), which appear to point to an infinite loop somewhere in KWin::Placement::placeSmart(). This only ever occurs when a new window is being opened, though I've never been able to get it to work consistently.

I haven't seen a stacktrace that goes as far as the VirtualDesktop RefCount thus far, but have seen them in AbstractClient::isCurrentTab(). It seems to mostly occurs just in the KWin::Placement::placeSmart() function directly.

Note that this didn't occur with the normal Kubuntu 19.04 build of KWin (which seems to be 5.15.4).

Alas, I don't have full debug symbols available at the moment, but here's an example stacktrace anyway:
#0  0x00007fafa5258d2e in KWin::Placement::placeSmart(KWin::AbstractClient*, QRect const&, KWin::Placement::Policy) () at /usr/lib/x86_64-linux-gnu/libkwin.so.5
#1  0x00007fafa525aa18 in KWin::Placement::place(KWin::AbstractClient*, QRect&, KWin::Placement::Policy, KWin::Placement::Policy) () at /usr/lib/x86_64-linux-gnu/libkwin.so.5
#2  0x00007fafa5348c7d in KWin::ShellClient::placeIn(QRect&) () at /usr/lib/x86_64-linux-gnu/libkwin.so.5
#3  0x00007fafa5348dd1 in KWin::ShellClient::finishInit() () at /usr/lib/x86_64-linux-gnu/libkwin.so.5
#4  0x00007fafa4407563 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007fafa002d81e in ffi_call_unix64 () at/usr/lib/x86_64-linux-gnu/libffi.so.6
#6  0x00007fafa002d1ef in ffi_call () at /usr/lib/x86_64-linux-gnu/libffi.so.6
#7  0x00007fafa1de68fd in  () at /usr/lib/x86_64-linux-gnu/libwayland-server.so.0
#8  0x00007fafa1de3379 in  () at /usr/lib/x86_64-linux-gnu/libwayland-server.so.0
#9  0x00007fafa1de4942 in wl_event_loop_dispatch () at /usr/lib/x86_64-linux-gnu/libwayland-server.so.0
#10 0x00007fafa4f05f2e in KWayland::Server::Display::Private::dispatch() () at /usr/lib/x86_64-linux-gnu/libKF5WaylandServer.so.5
#11 0x00007fafa4407563 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x00007fafa4412bd9 in QSocketNotifier::activated(int, QSocketNotifier::QPrivateSignal) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#13 0x00007fafa4412f21 in QSocketNotifier::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#14 0x00007fafa47f4551 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#15 0x00007fafa47fb930 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#16 0x00007fafa43dd8e9 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x00007fafa442e276 in QEventDispatcherUNIXPrivate::activateSocketNotifiers() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x00007fafa442e587 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#19 0x00007faf9ced762d in  () at /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/KWinQpaPlugin.so
#20 0x00007fafa43dc5bb in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#21 0x00007fafa43e45e2 in QCoreApplication::exec() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5


Hope that helps.
Comment 5 David Gow 2019-06-04 01:25:45 UTC 
I've tried to reproduce this on the latest KWin git (c62650394) over the last few days, and haven't been able to, so maybe it's fixed. I'd certainly have expected it to show up by now if it were still happening, though my environment for git KWin is slightly different (started from a VT instead of SDDM).

So… maybe fixed?
Comment 6 David Gow 2019-06-04 01:51:19 UTC 
Okay, it seems that I spoke too soon: I just got the hang again.

I have better debug symbols now, so here's an updated (example) stacktrace. As before, it appears to be an infinite loop in KWin::Placement::placeSmart():

#0  0x00007f9e7d2211d4 in KWin::Client::metaObject() const (this=<optimized out>) at /home/david/kde/build/kwin/kwin_autogen/EWIEGA46WW/moc_client.cpp:264
#1  0x00007f9e7c1dab69 in QMetaObject::cast(QObject const*) const () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#2  0x00007f9e7d0d9c4d in qobject_cast<KWin::AbstractClient*>(QObject*) (object=<optimized out>) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:499
#3  0x00007f9e7d0d9c4d in KWin::Placement::placeSmart(KWin::AbstractClient*, QRect const&, KWin::Placement::Policy) (this=<optimized out>, c=c@entry=0x5623225705c0, area=...) at /home/david/kde/src/kwin/placement.cpp:243
#4  0x00007f9e7d0db9d8 in KWin::Placement::place(KWin::AbstractClient*, QRect&, KWin::Placement::Policy, KWin::Placement::Policy)
    (this=<optimized out>, c=0x5623225705c0, area=..., policy=<optimized out>, nextPlacement=<optimized out>) at /home/david/kde/src/kwin/placement.cpp:106
#5  0x00007f9e7d1ca38d in KWin::ShellClient::placeIn(QRect&) (this=this@entry=0x5623225705c0, area=...) at /home/david/kde/src/kwin/placement.h:107
#6  0x00007f9e7d1ca849 in KWin::ShellClient::finishInit() (this=0x5623225705c0) at /home/david/kde/src/kwin/shell_client.cpp:378
#7  0x00007f9e7c1fb563 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x00007f9e77e0381e in ffi_call_unix64 () at /usr/lib/x86_64-linux-gnu/libffi.so.6
#9  0x00007f9e77e031ef in ffi_call () at /usr/lib/x86_64-linux-gnu/libffi.so.6
#10 0x00007f9e79bc88fd in  () at /usr/lib/x86_64-linux-gnu/libwayland-server.so.0
#11 0x00007f9e79bc5379 in  () at /usr/lib/x86_64-linux-gnu/libwayland-server.so.0
#12 0x00007f9e79bc6942 in wl_event_loop_dispatch () at /usr/lib/x86_64-linux-gnu/libwayland-server.so.0
#13 0x00007f9e7cd083ae in KWayland::Server::Display::Private::dispatch() (this=<optimized out>) at /home/david/kde/src/kwayland/src/server/display.cpp:147
#14 0x00007f9e7c1fb563 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x00007f9e7c206bd9 in QSocketNotifier::activated(int, QSocketNotifier::QPrivateSignal) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x00007f9e7c206f21 in QSocketNotifier::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x00007f9e7c5e8551 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#18 0x00007f9e7c5ef930 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#19 0x00007f9e7c1d18e9 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#20 0x00007f9e7c222276 in QEventDispatcherUNIXPrivate::activateSocketNotifiers() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#21 0x00007f9e7c222587 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#22 0x00007f9e74cac65d in QUnixEventDispatcherQPA::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /home/david/kde/usr/lib/x86_64-linux-gnu/plugins/platforms/KWinQpaPlugin.so
#23 0x00007f9e7c1d05bb in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#24 0x00007f9e7c1d85e2 in QCoreApplication::exec() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#25 0x000056231f48c25e in main(int, char**) (argc=<optimized out>, argv=<optimized out>) at /home/david/kde/src/kwin/main_wayland.cpp:676


Sorry for the spam — let me know if there's anything more I should be looking at.
Comment 7 Vlad Zahorodnii 2019-06-04 07:44:43 UTC 
@David Gow please file a separate bug report for that. This and your backtrace(s) look different.
Comment 8 Roman Gilg 2019-06-05 06:37:54 UTC 
Might be the same issue because of the placement calls in the backtrace.
Comment 9 Aleix Pol 2022-01-19 15:34:53 UTC 
Have not seen this crash in years, seems like it was a bogus call to a Toplevel, it doesn't seem to have anything to do with the refcounting itself.

Please reopen if it's still failing on stable releases.