Bug 312712

Summary: Assert on "kwin --restart &"
Product: [Plasma] kwin Reporter: Christoph Feck <cfeck>
Component: compositingAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED FIXED    
Severity: crash Keywords: regression
Priority: NOR Flags: mgraesslin: ReviewRequest+
Version: unspecified   
Target Milestone: 4.10 RC 3   
Platform: Compiled Sources   
OS: Linux   
URL: https://git.reviewboard.kde.org/r/108321/
Latest Commit: Version Fixed In: 4.10
Sentry Crash Report:

Description Christoph Feck 2013-01-05 21:54:12 UTC
Application: kwin (4.10.60)
KDE Platform Version: 4.10.60 (Compiled from sources)
Qt Version: 4.8.4
Operating System: Linux 3.7.1-1-desktop i686
Distribution: "openSUSE 12.2 (i586)"

-- Information about the crash:
- What I was doing when the application crashed:

Since kwin leaks memory over time, I sometimes simply run "kwin --restart &" from shell. Since a few days, I get this assert.

Line numbers are from yesterday's master.

The crash can be reproduced some of the time.

-- Backtrace:
Application: KWin (kwin), signal: Aborted
Using host libthread_db library "/lib/libthread_db.so.1".
[KCrash Handler]
#7  0xb77b2424 in __kernel_vsyscall ()
#8  0xb4fb731f in raise () from /lib/libc.so.6
#9  0xb4fb8c03 in abort () from /lib/libc.so.6
#10 0xb5e81e3e in qt_message_output(QtMsgType, char const*) () from /usr/lib/libQtCore.so.4
#11 0xb5e82039 in ?? () from /usr/lib/libQtCore.so.4
#12 0xb5e82158 in qFatal(char const*, ...) () from /usr/lib/libQtCore.so.4
#13 0xb5e821d5 in qt_assert(char const*, char const*, int) () from /usr/lib/libQtCore.so.4
#14 0xb765ae9b in KWin::Compositor::self () at /local/git/KDE/base/kde-workspace/kwin/composite.h:142
#15 0xb76d71df in KWin::Toplevel::compositing (this=0x90027e8) at /local/git/KDE/base/kde-workspace/kwin/composite.cpp:921
#16 0xb76d7afb in KWin::Toplevel::addWorkspaceRepaint (this=0x90027e8, r2=...) at /local/git/KDE/base/kde-workspace/kwin/composite.cpp:1092
#17 0xb765bd64 in KWin::Client::releaseWindow (this=0x90027e8, on_shutdown=true) at /local/git/KDE/base/kde-workspace/kwin/client.cpp:269
#18 0xb76430de in KWin::Workspace::~Workspace (this=0x8dd25f0, __in_chrg=<optimized out>) at /local/git/KDE/base/kde-workspace/kwin/workspace.cpp:516
#19 0xb764369d in KWin::Workspace::~Workspace (this=0x8dd25f0, __in_chrg=<optimized out>) at /local/git/KDE/base/kde-workspace/kwin/workspace.cpp:550
#20 0xb767a729 in KWin::Application::lostSelection (this=0xbfe61884) at /local/git/KDE/base/kde-workspace/kwin/main.cpp:353
#21 0xb767ba95 in KWin::Application::qt_static_metacall (_o=0xbfe61884, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0xbfe611ac) at /local/build/KDE/base/kde-workspace/kwin/main.moc:51
#22 0xb5fb79b2 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4
#23 0xb672a795 in KSelectionOwner::lostOwnership (this=0xbfe61890) at /local/build/KDE/libs/kdelibs/kdeui/kmanagerselection.moc:98
#24 0xb6729b65 in KSelectionOwner::filterEvent (this=0xbfe61890, ev_P=0xbfe6164c) at /local/git/KDE/libs/kdelibs/kdeui/util/kmanagerselection.cpp:224
#25 0xb672aad3 in KSelectionOwner::Private::x11Event (this=0x8dd1600, ev_P=0xbfe6164c) at /local/git/KDE/libs/kdelibs/kdeui/util/kmanagerselection.cpp:80
#26 0xb66b011b in KAppX11HackWidget::publicx11Event (this=0x8dd1600, e=0xbfe6164c) at /local/git/KDE/libs/kdelibs/kdeui/kernel/kapplication.cpp:918
#27 0xb66ae7b8 in KApplication::x11EventFilter (this=0xbfe61884, _event=0xbfe6164c) at /local/git/KDE/libs/kdelibs/kdeui/kernel/kapplication.cpp:930
#28 0xb767a7b8 in KWin::Application::x11EventFilter (this=0xbfe61884, e=0xbfe6164c) at /local/git/KDE/base/kde-workspace/kwin/main.cpp:363
#29 0xb54e7ab6 in ?? () from /usr/lib/libQtGui.so.4
#30 0xb54f61c2 in QApplication::x11ProcessEvent(_XEvent*) () from /usr/lib/libQtGui.so.4
#31 0xb552145d in ?? () from /usr/lib/libQtGui.so.4
#32 0xb5f9e12c in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#33 0xb5f9e421 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#34 0xb5fa36da in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4
#35 0xb546ca14 in QApplication::exec() () from /usr/lib/libQtGui.so.4
#36 0xb767b993 in kdemain (argc=1, argv=0xbfe61ac4) at /local/git/KDE/base/kde-workspace/kwin/main.cpp:536
#37 0x08048951 in main (argc=1, argv=0xbfe61ac4) at /local/build/KDE/base/kde-workspace/kwin/kwin_dummy.cpp:3

Reported using DrKonqi
Comment 1 Thomas Lübking 2013-01-05 22:10:20 UTC
comes with commit 1fefaa9e1e7f6c53c5dca283f12653432d6130cb to fix bug #308040

The assert is wrong.
Comment 2 Thomas Lübking 2013-01-05 22:14:26 UTC
... resp. Toplevel::compositing() could just wrap static Compositor::compositing()

Martin's choice ;-)
Comment 3 Martin Flöser 2013-01-06 07:45:16 UTC
> Since kwin leaks memory over time, I sometimes simply run "kwin --restart &" from shell. Since a few days, I get this assert.
could you please run valgrind on it to see where it leaks memory. I'm not aware of leaks and due to the way I work cannot see any leaks over time.

@Thomas: I think there was a reason why Toplevel::compositing() is not wrapping the Compositor::compositing(). I don't remember the details as I don't have the code open just now to look into it.
Comment 4 Thomas Lübking 2013-01-06 11:01:57 UTC
I don't think so ;-)


 bool Workspace::compositing() const
 {
    return m_compositor && m_compositor->hasScene();
 }
 
 bool Toplevel::compositing() const
 {
    Compositor *c = Compositor::self();
    return c && c->hasScene();
 }

class Compositor {
static bool compositing() {
        return s_compositor != NULL && s_compositor->isActive();
    }
}

while three different approaches, they effectively do all the same
- m_compositor points Compositor::self() being s_compositor
- bool Compositor::isActive() {  return !m_finishing && hasScene(); }

the only difference is the invocation of m_finishing being toggled around Workspace::finishCompositing() and thus impacting Scene::windowClosed/Deleted and Toplevel::finishCompositing - but whenever it's true, one should no longer access the compositor - i'd say.

The epic difference here is that for Toplevel::compositing there's an assert on the compositor singleton (which we can't hold because of the other bug - windows are apparently released after the compositor got nuked)
Comment 5 Martin Flöser 2013-01-06 12:16:17 UTC
yeah, the finishing is the important part which needs to be around.

But given the code it should be possible to wrap the Toplevel::compositing() around Workspace::compositing()
Comment 6 Martin Flöser 2013-01-14 14:40:57 UTC
Git commit 048fe5397dbdabb791c4082f3a56ef23942d3bac by Martin Gräßlin.
Committed on 10/01/2013 at 10:10.
Pushed by graesslin into branch 'KDE/4.10'.

Remove asserts from Compositor and wrap Toplevel::compositing() around Workspace::compositing()
FIXED-IN: 4.10
REVIEW: 108321

M  +1    -2    kwin/composite.cpp
M  +0    -1    kwin/composite.h
M  +5    -5    kwin/workspace.h

http://commits.kde.org/kde-workspace/048fe5397dbdabb791c4082f3a56ef23942d3bac