Bug 400854 - kwin crash when restarting IntelliJ application
Summary: kwin crash when restarting IntelliJ application
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.13.5
Platform: Debian testing Linux
: NOR crash
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: drkonqi
Depends on:
Blocks:
 
Reported: 2018-11-08 17:53 UTC by Marcus Better
Modified: 2019-02-15 10:31 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Better 2018-11-08 17:53:48 UTC
Application: kwin_x11 (5.13.5)

Qt Version: 5.11.2
Frameworks Version: 5.49.0
Operating System: Linux 4.19.1-better x86_64
Distribution: Debian GNU/Linux testing (buster)

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

Was restarting the IntelliJ IDEA application (the feature that restarts the IDE after a plugin update).

-- Backtrace:
Application: Kwin (kwin_x11), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f1e200bb940 (LWP 2574))]

Thread 5 (Thread 0x7f1e1d1b1700 (LWP 4321)):
#0  0x00007f1e28ad6e6c in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x55e668c385a0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x55e668c38550, cond=0x55e668c38578) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x55e668c38578, mutex=0x55e668c38550) at pthread_cond_wait.c:655
#3  0x00007f1d87950e2b in cnd_wait (mtx=0x55e668c38550, cond=0x55e668c38578) at ../../../include/c11/threads_posix.h:155
#4  util_queue_thread_func (input=input@entry=0x55e668d596e0) at ../../../src/util/u_queue.c:255
#5  0x00007f1d87950b57 in impl_thrd_routine (p=<optimized out>) at ../../../include/c11/threads_posix.h:87
#6  0x00007f1e28ad0f2a in start_thread (arg=0x7f1e1d1b1700) at pthread_create.c:463
#7  0x00007f1e2b2b9edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 4 (Thread 0x7f1e0f3fe700 (LWP 2702)):
#0  0x00007f1e28ad6e6c in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7f1e298c4fb8 <QTWTF::pageheap_memory+57592>) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x7f1e298c4f68 <QTWTF::pageheap_memory+57512>, cond=0x7f1e298c4f90 <QTWTF::pageheap_memory+57552>) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x7f1e298c4f90 <QTWTF::pageheap_memory+57552>, mutex=0x7f1e298c4f68 <QTWTF::pageheap_memory+57512>) at pthread_cond_wait.c:655
#3  0x00007f1e297cde2a in QTWTF::TCMalloc_PageHeap::scavengerThread (this=0x7f1e298b6ec0 <QTWTF::pageheap_memory>) at ../3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.cpp:2359
#4  0x00007f1e297cde49 in QTWTF::TCMalloc_PageHeap::runScavengerThread (context=<optimized out>) at ../3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.cpp:1464
#5  0x00007f1e28ad0f2a in start_thread (arg=0x7f1e0f3fe700) at pthread_create.c:463
#6  0x00007f1e2b2b9edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 3 (Thread 0x7f1e0ffff700 (LWP 2699)):
#0  0x00007f1e2b2af836 in __GI_ppoll (fds=fds@entry=0x7f1e08000d28, nfds=nfds@entry=1, timeout=<optimized out>, timeout@entry=0x0, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39
#1  0x00007f1e29ea1d11 in ppoll (__ss=<optimized out>, __timeout=<optimized out>, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/poll2.h:77
#2  qt_ppoll (timeout_ts=0x0, nfds=1, fds=0x7f1e08000d28) at kernel/qcore_unix.cpp:132
#3  qt_safe_poll (fds=0x7f1e08000d28, nfds=nfds@entry=1, timeout_ts=timeout_ts@entry=0x0) at kernel/qcore_unix.cpp:153
#4  0x00007f1e29ea3189 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at ../../include/QtCore/../../src/corelib/tools/qarraydata.h:209
#5  0x00007f1e29e52d0b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at ../../include/QtCore/../../src/corelib/global/qflags.h:140
#6  0x00007f1e29ca20c6 in QThread::exec() () at ../../include/QtCore/../../src/corelib/global/qflags.h:120
#7  0x00007f1e28300355 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#8  0x00007f1e29cabc97 in QThreadPrivate::start(void*) () at thread/qthread_unix.cpp:367
#9  0x00007f1e28ad0f2a in start_thread (arg=0x7f1e0ffff700) at pthread_create.c:463
#10 0x00007f1e2b2b9edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7f1e1e66e700 (LWP 2608)):
#0  0x00007f1e29c9ee7f in QMutex::unlock (this=this@entry=0x55e6689056b0) at /usr/include/c++/8/bits/atomic_base.h:742
#1  0x00007f1e29ea301c in QMutexLocker::unlock (this=<synthetic pointer>) at ../../include/QtCore/../../src/corelib/thread/qmutex.h:240
#2  QMutexLocker::~QMutexLocker (this=<synthetic pointer>, __in_chrg=<optimized out>) at ../../include/QtCore/../../src/corelib/thread/qmutex.h:213
#3  QThreadData::canWaitLocked (this=0x55e668905680) at ../../include/QtCore/5.11.2/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:254
#4  QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at kernel/qeventdispatcher_unix.cpp:472
#5  0x00007f1e29e52d0b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at ../../include/QtCore/../../src/corelib/global/qflags.h:140
#6  0x00007f1e29ca20c6 in QThread::exec() () at ../../include/QtCore/../../src/corelib/global/qflags.h:120
#7  0x00007f1e27ddd545 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#8  0x00007f1e29cabc97 in QThreadPrivate::start(void*) () at thread/qthread_unix.cpp:367
#9  0x00007f1e28ad0f2a in start_thread (arg=0x7f1e1e66e700) at pthread_create.c:463
#10 0x00007f1e2b2b9edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7f1e200bb940 (LWP 2574)):
[KCrash Handler]
#6  0x0000000000000000 in ?? ()
#7  0x00007f1e2afce9ad in KWin::Workspace::constrainedStackingOrder (this=this@entry=0x55e6689bddc0) at ./layers.cpp:504
#8  0x00007f1e2afcf1f8 in KWin::Workspace::updateStackingOrder (this=0x55e6689bddc0, propagate_new_clients=<optimized out>) at ./layers.cpp:120
#9  0x00007f1e2afcf5c0 in KWin::Workspace::blockStackingUpdates (this=this@entry=0x55e6689bddc0, block=block@entry=false) at ./layers.cpp:597
#10 0x00007f1e2af7fdd8 in KWin::StackingUpdatesBlocker::~StackingUpdatesBlocker (this=<synthetic pointer>, __in_chrg=<optimized out>) at ./workspace.h:646
#11 KWin::Client::destroyClient (this=this@entry=0x55e6693ffb80) at ./client.cpp:285
#12 0x00007f1e2afda751 in KWin::Client::unmapNotifyEvent (this=0x55e6693ffb80, e=<optimized out>) at ./events.cpp:639
#13 0x00007f1e2afdde7b in KWin::Client::windowEvent (this=0x55e6693ffb80, e=e@entry=0x7f1e18005180) at ./events.cpp:481
#14 0x00007f1e2afdec2a in KWin::Workspace::workspaceEvent(xcb_generic_event_t*) () at ./events.cpp:261
#15 0x00007f1e29e51b8f in QAbstractEventDispatcher::filterNativeEvent(QByteArray const&, void*, long*) () at kernel/qabstracteventdispatcher.cpp:466
#16 0x00007f1e1fc3ecb0 in QXcbConnection::handleXcbEvent (this=this@entry=0x55e6688a8360, event=event@entry=0x7f1e18005180) at qxcbnativeinterface.h:101
#17 0x00007f1e1fc3f843 in QXcbConnection::processXcbEvents() () at qxcbconnection.cpp:1790
#18 0x00007f1e29e7db42 in QObject::event(QEvent*) () at kernel/qobject.cpp:1251
#19 0x00007f1e2a7cc491 in QApplicationPrivate::notify_helper (this=this@entry=0x55e668871680, receiver=receiver@entry=0x55e6688a8360, e=e@entry=0x7f1e1801aeb0) at kernel/qapplication.cpp:3727
#20 0x00007f1e2a7d3ad0 in QApplication::notify(QObject*, QEvent*) () at kernel/qapplication.cpp:3486
#21 0x00007f1e29e54039 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at ../../include/QtCore/5.11.2/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307
#22 0x00007f1e29e5702b in QCoreApplication::sendEvent (event=0x7f1e1801aeb0, receiver=<optimized out>) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:234
#23 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at kernel/qcoreapplication.cpp:1745
#24 0x00007f1e29ea2ffb in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at kernel/qeventdispatcher_unix.cpp:466
#25 0x00007f1e1fcd0aed in QUnixEventDispatcherQPA::processEvents (this=<optimized out>, flags=...) at qunixeventdispatcher.cpp:68
#26 0x00007f1e29e52d0b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at ../../include/QtCore/../../src/corelib/global/qflags.h:140
#27 0x00007f1e29e5ae82 in QCoreApplication::exec() () at ../../include/QtCore/../../src/corelib/global/qflags.h:120
#28 0x00007f1e2b38947b in kdemain (argc=<optimized out>, argv=0x7ffecf338cf8) at ./main_x11.cpp:468
#29 0x00007f1e2b1e4b17 in __libc_start_main (main=0x55e6681fe050 <main>, argc=3, argv=0x7ffecf338cf8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffecf338ce8) at ../csu/libc-start.c:310
#30 0x000055e6681fe08a in _start ()

The reporter indicates this bug may be a duplicate of or related to bug 397514, bug 396975, bug 394701, bug 392412, bug 391395, bug 389201.

Possible duplicates by query: bug 397514, bug 396975, bug 394701, bug 392412, bug 391395.

Reported using DrKonqi
Comment 1 Vlad Zahorodnii 2018-11-08 19:29:07 UTC
It looks like we're re-inserting deleted Client's.

For example, if we have the following unconstrained stacking order

  unconstrained_stacking_order:
    { 0x5632110c9870, 0x5632110aac50, 0x5632110ddf50, 0x5632111b3100 }

and releaseWindow is called on Client 0x5632111b3100 (the last one), then Workspace::addDeleted will replace that client with a corresponding Deleted instance 0x563211181860

  unconstrained_stacking_order (after addDeleted was called):
    { 0x5632110c9870, 0x5632110aac50, 0x5632110ddf50, 0x563211181860 }

but when Workspace::constrainedStackingOrder is called, we have the following unconstrained stacking order

  unconstrained_stacking_order:
    { 0x5632110c9870, 0x5632110aac50, 0x5632110ddf50, 0x563211181860, 0x5632111b3100 }
Comment 2 Vlad Zahorodnii 2018-11-08 19:56:27 UTC
It looks like in my case, raiseClient is called, which in its turn, adds the deleted Client back to unconstrained stacking order.
Comment 3 Vlad Zahorodnii 2018-11-08 20:17:16 UTC
In case of bug 392412, it looks like sendClientToDesktop indirectly triggers raiseClient.

---

@Marcus Do you use some fancy scripts to open/maximize windows on new virtual desktops?
Comment 4 Marcus Better 2018-11-11 22:13:28 UTC
No, I have a plain Debian install. No fancy scripts that I know of.
Comment 5 Vlad Zahorodnii 2018-11-26 08:51:06 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 392412

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 6 Vlad Zahorodnii 2018-11-26 09:25:32 UTC
@Marcus Does this happen only when restarting IntelliJ IDEA?
Comment 7 Marcus Better 2018-11-27 01:23:34 UTC
I cannot reproduce it consistently, so not sure in which scenarios it happens.
Comment 8 Vlad Zahorodnii 2019-02-15 10:31:57 UTC
Maybe it's fixed in 5.15.0 (I'm still not sure whether we covered all cases, it's quite hard to reproduce this bug). If the crash still happens, please reopen this bug report. Thanks.