Bug 392412 - KWin crash when KWin script handler for clientRemoved
Summary: KWin crash when KWin script handler for clientRemoved
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.12.3
Platform: Arch Linux Linux
: NOR crash
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: drkonqi, triaged
: 402546 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-03-27 13:35 UTC by Gonzalo Peci
Modified: 2019-02-02 13:04 UTC (History)
2 users (show)

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


Attachments
New crash information added by DrKonqi (5.21 KB, text/plain)
2019-02-02 03:40 UTC, qq767026763
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gonzalo Peci 2018-03-27 13:35:26 UTC
Application: kwin_x11 (5.12.3)

Qt Version: 5.10.1
Frameworks Version: 5.44.0
Operating System: Linux 4.15.12-1-zen x86_64
Distribution: "Arch Linux"

-- Information about the crash:
- What I was doing when the application crashed:
Testing this KWin script that dinamically adds and removes virtual desktops. I can consistently reproduce this by opening one app (goes to vdesktop 2) open a 3rd one (goes to vdesktop 3) close app on vdesktop 3, close app on vdesktop 2.
On close of vdesktop 2 app we get the crash. No other apps are running at the time.


- Custom settings of the application:

KWin Script:
workspace.clientAdded.connect(function(client) {
    if (client.skipTaskbar || client.modal || client.transient){
      return;
    }
    workspace.desktops = workspace.desktops+1;
    workspace.currentDesktop = workspace.desktops;
    client.desktop = workspace.currentDesktop;
});

workspace.clientRemoved.connect(function(client) {
    if (client.skipTaskbar || client.modal || client.transient){
      return;
    }
    workspace.desktops = workspace.desktops-1;
});

The crash can be reproduced every time.

-- Backtrace:
Application: KWin (kwin_x11), signal: Segmentation fault
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f1830883840 (LWP 4071))]

Thread 6 (Thread 0x7f180ebdc700 (LWP 5113)):
#0  0x00007f18291ef6fd in pthread_cond_timedwait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0
#1  0x00007f182d38ee61 in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib/libQt5Core.so.5
#2  0x00007f182d38ad31 in  () at /usr/lib/libQt5Core.so.5
#3  0x00007f182d38dacd in  () at /usr/lib/libQt5Core.so.5
#4  0x00007f18291e908c in start_thread () at /usr/lib/libpthread.so.0
#5  0x00007f18301fee7f in clone () at /usr/lib/libc.so.6

Thread 5 (Thread 0x7f17f77fe700 (LWP 4167)):
#0  0x00007f18291ef3bd in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0
#1  0x00007f182c4a6f77 in  () at /usr/lib/libQt5Script.so.5
#2  0x00007f182c4a6fb9 in  () at /usr/lib/libQt5Script.so.5
#3  0x00007f18291e908c in start_thread () at /usr/lib/libpthread.so.0
#4  0x00007f18301fee7f in clone () at /usr/lib/libc.so.6

Thread 4 (Thread 0x7f180df79700 (LWP 4139)):
#0  0x00007f18301f4a76 in ppoll () at /usr/lib/libc.so.6
#1  0x00007f182d5d2dc3 in qt_safe_poll(pollfd*, unsigned long, timespec const*) () at /usr/lib/libQt5Core.so.5
#2  0x00007f182d5d455f in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5
#3  0x00007f182d57932b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5
#4  0x00007f182d38872e in QThread::exec() () at /usr/lib/libQt5Core.so.5
#5  0x00007f1827cb2379 in  () at /usr/lib/libQt5Qml.so.5
#6  0x00007f182d38dacd in  () at /usr/lib/libQt5Core.so.5
#7  0x00007f18291e908c in start_thread () at /usr/lib/libpthread.so.0
#8  0x00007f18301fee7f in clone () at /usr/lib/libc.so.6

Thread 3 (Thread 0x7f180ffff700 (LWP 4126)):
#0  0x00007f18301f4a76 in ppoll () at /usr/lib/libc.so.6
#1  0x00007f182d5d2dc3 in qt_safe_poll(pollfd*, unsigned long, timespec const*) () at /usr/lib/libQt5Core.so.5
#2  0x00007f182d5d455f in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5
#3  0x00007f182d57932b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5
#4  0x00007f182d38872e in QThread::exec() () at /usr/lib/libQt5Core.so.5
#5  0x00007f1826b54416 in  () at /usr/lib/libQt5DBus.so.5
#6  0x00007f182d38dacd in  () at /usr/lib/libQt5Core.so.5
#7  0x00007f18291e908c in start_thread () at /usr/lib/libpthread.so.0
#8  0x00007f18301fee7f in clone () at /usr/lib/libc.so.6

Thread 2 (Thread 0x7f18169ed700 (LWP 4112)):
#0  0x00007f18301f497b in poll () at /usr/lib/libc.so.6
#1  0x00007f182f0f1180 in  () at /usr/lib/libxcb.so.1
#2  0x00007f182f0f2e4b in xcb_wait_for_event () at /usr/lib/libxcb.so.1
#3  0x00007f1817ad882a in  () at /usr/lib/libQt5XcbQpa.so.5
#4  0x00007f182d38dacd in  () at /usr/lib/libQt5Core.so.5
#5  0x00007f18291e908c in start_thread () at /usr/lib/libpthread.so.0
#6  0x00007f18301fee7f in clone () at /usr/lib/libc.so.6

Thread 1 (Thread 0x7f1830883840 (LWP 4071)):
[KCrash Handler]
#6  0x0000000000000000 in  ()
#7  0x00007f182fced9dd in KWin::Workspace::constrainedStackingOrder() () at /usr/lib/libkwin.so.5
#8  0x00007f182fcee7c1 in KWin::Workspace::updateStackingOrder(bool) () at /usr/lib/libkwin.so.5
#9  0x00007f182fceeb61 in KWin::Workspace::blockStackingUpdates(bool) () at /usr/lib/libkwin.so.5
#10 0x00007f182fc95e7d in KWin::Client::releaseWindow(bool) () at /usr/lib/libkwin.so.5
#11 0x00007f182fcfb2c3 in KWin::Client::unmapNotifyEvent(xcb_unmap_notify_event_t*) () at /usr/lib/libkwin.so.5
#12 0x00007f182fcfee64 in KWin::Client::windowEvent(xcb_generic_event_t*) () at /usr/lib/libkwin.so.5
#13 0x00007f182fcffe78 in KWin::Workspace::workspaceEvent(xcb_generic_event_t*) () at /usr/lib/libkwin.so.5
#14 0x00007f182d577d5f in QAbstractEventDispatcher::filterNativeEvent(QByteArray const&, void*, long*) () at /usr/lib/libQt5Core.so.5
#15 0x00007f1817ada3f2 in QXcbConnection::handleXcbEvent(xcb_generic_event_t*) () at /usr/lib/libQt5XcbQpa.so.5
#16 0x00007f1817adb07e in QXcbConnection::processXcbEvents() () at /usr/lib/libQt5XcbQpa.so.5
#17 0x00007f182d5ac062 in QObject::event(QEvent*) () at /usr/lib/libQt5Core.so.5
#18 0x00007f182e2f8fec in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5
#19 0x00007f182e3009c6 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5
#20 0x00007f182d57acf0 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/libQt5Core.so.5
#21 0x00007f182d57d956 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib/libQt5Core.so.5
#22 0x00007f182d5d4376 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5
#23 0x00007f1817b6071e in  () at /usr/lib/libQt5XcbQpa.so.5
#24 0x00007f182d57932b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5
#25 0x00007f182d582728 in QCoreApplication::exec() () at /usr/lib/libQt5Core.so.5
#26 0x00007f18304c8719 in kdemain () at /usr/lib/libkdeinit5_kwin_x11.so
#27 0x00007f1830129f4a in __libc_start_main () at /usr/lib/libc.so.6
#28 0x000055e2486c776a in _start ()

The reporter indicates this bug may be a duplicate of or related to bug 389201.

Possible duplicates by query: bug 389201.

Reported using DrKonqi
Comment 1 Martin Flöser 2018-03-27 15:54:04 UTC
Unfortunately the backtrace is lacking debug symbols. If you are able to reproduce please install debug packages and attach a new backtrace
Comment 2 Gonzalo Peci 2018-03-31 18:03:10 UTC
Im on Arch, unfortunately for certain things that will mean manually compiling. Which packages would need to have debug symbols?

Thanks
Comment 3 Martin Flöser 2018-03-31 18:21:54 UTC
from the backtrace it looks like KWin would be sufficient
Comment 4 Andrew Crouthamel 2018-09-28 03:30:31 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 5 Andrew Crouthamel 2018-10-29 02:16:14 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!
Comment 6 Vlad Zahorodnii 2018-11-26 08:51:05 UTC
Git commit 8af6d4f5dc74385a9d52820562162dc190f452ff by Vlad Zagorodniy.
Committed on 26/11/2018 at 08:50.
Pushed by vladz into branch 'master'.

[x11] Emit clientRemoved after client was removed

Summary:
Currently, there is a guarantee that a client, which is about to be removed,
is no longer in the stacking order(both in constrained and unconstrained)
when Workspace::removeClient is called. However, because the client gets
removed from m_allClients after clientRemoved is emitted, it can be
re-inserted back into the stacking order.

In general, the pattern is to do some work and then notify others about
what you've done by emitting a signal. In the case of Workspace::removeClient,
we emit clientRemoved way before the client actually gets removed.
Related: bug 400854

Test Plan:
* Enable the following script:

```lang=js
workspace.clientAdded.connect(function (client) {
    if (client.skipTaskbar || client.modal || client.transient) {
        return;
    }
    workspace.desktops = workspace.desktops + 1;
    workspace.currentDesktop = workspace.desktops;
    client.desktop = workspace.currentDesktop;
});

workspace.clientRemoved.connect(function (client) {
    if (client.skipTaskbar || client.modal || client.transient) {
        return;
    }
    workspace.desktops = workspace.desktops - 1;
});
```

* Open an app, close the app.

Reviewers: #kwin, graesslin

Reviewed By: #kwin, graesslin

Subscribers: graesslin, kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D17069

M  +2    -2    workspace.cpp

https://commits.kde.org/kwin/8af6d4f5dc74385a9d52820562162dc190f452ff
Comment 7 David Edmundson 2018-12-25 07:50:22 UTC
*** Bug 402546 has been marked as a duplicate of this bug. ***
Comment 8 Gonzalo Peci 2019-01-25 23:16:54 UTC
(In reply to Vlad Zagorodniy from comment #6)
> Git commit 8af6d4f5dc74385a9d52820562162dc190f452ff by Vlad Zagorodniy.
> Committed on 26/11/2018 at 08:50.
> Pushed by vladz into branch 'master'.
> 
> [x11] Emit clientRemoved after client was removed
> 
> Summary:
> Currently, there is a guarantee that a client, which is about to be removed,
> is no longer in the stacking order(both in constrained and unconstrained)
> when Workspace::removeClient is called. However, because the client gets
> removed from m_allClients after clientRemoved is emitted, it can be
> re-inserted back into the stacking order.
> 
> In general, the pattern is to do some work and then notify others about
> what you've done by emitting a signal. In the case of
> Workspace::removeClient,
> we emit clientRemoved way before the client actually gets removed.
> Related: bug 400854
> 
> Test Plan:
> * Enable the following script:
> 
> ```lang=js
> workspace.clientAdded.connect(function (client) {
>     if (client.skipTaskbar || client.modal || client.transient) {
>         return;
>     }
>     workspace.desktops = workspace.desktops + 1;
>     workspace.currentDesktop = workspace.desktops;
>     client.desktop = workspace.currentDesktop;
> });
> 
> workspace.clientRemoved.connect(function (client) {
>     if (client.skipTaskbar || client.modal || client.transient) {
>         return;
>     }
>     workspace.desktops = workspace.desktops - 1;
> });
> ```
> 
> * Open an app, close the app.
> 
> Reviewers: #kwin, graesslin
> 
> Reviewed By: #kwin, graesslin
> 
> Subscribers: graesslin, kwin
> 
> Tags: #kwin
> 
> Differential Revision: https://phabricator.kde.org/D17069
> 
> M  +2    -2    workspace.cpp
> 
> https://commits.kde.org/kwin/8af6d4f5dc74385a9d52820562162dc190f452ff

Do you know if this will be included in 15.5? Amazing that this was fix by the way. Sorry I could not provide debug symbols.
Comment 9 Vlad Zahorodnii 2019-01-25 23:18:42 UTC
Yes, it will be included in 5.15.
Comment 10 qq767026763 2019-02-02 03:40:37 UTC
Created attachment 117784 [details]
New crash information added by DrKonqi

kwin_x11 (5.14.5) using Qt 5.12.0

- What I was doing when the application crashed:
I am just playing cs:go  when press tab button

-- Backtrace (Reduced):
#6  0x0000000000000000 in  ()
#7  0x00007fbd1da8abdd in KWin::Workspace::constrainedStackingOrder() () at /usr/lib/libkwin.so.5
#8  0x00007fbd1da8b429 in KWin::Workspace::updateStackingOrder(bool) () at /usr/lib/libkwin.so.5
#9  0x00007fbd1da8b801 in KWin::Workspace::blockStackingUpdates(bool) () at /usr/lib/libkwin.so.5
#10 0x00007fbd1da394c7 in KWin::Client::destroyClient() () at /usr/lib/libkwin.so.5
Comment 11 Vlad Zahorodnii 2019-02-02 13:04:53 UTC
(In reply to qq767026763 from comment #10)
> Created attachment 117784 [details]
> New crash information added by DrKonqi
> 
> kwin_x11 (5.14.5) using Qt 5.12.0
> 
> - What I was doing when the application crashed:
> I am just playing cs:go  when press tab button
> 
> -- Backtrace (Reduced):
> #6  0x0000000000000000 in  ()
> #7  0x00007fbd1da8abdd in KWin::Workspace::constrainedStackingOrder() () at
> /usr/lib/libkwin.so.5
> #8  0x00007fbd1da8b429 in KWin::Workspace::updateStackingOrder(bool) () at
> /usr/lib/libkwin.so.5
> #9  0x00007fbd1da8b801 in KWin::Workspace::blockStackingUpdates(bool) () at
> /usr/lib/libkwin.so.5
> #10 0x00007fbd1da394c7 in KWin::Client::destroyClient() () at
> /usr/lib/libkwin.so.5

If you're able to reproduce the crash in 5.15, please file a new bug report. I'm still not quite sure whether I fixed the crash because it's hard to reproduce it.