Bug 389221 - when I cancel a drag operation in Dolphin, Wayland session crashes and my system goes to login screen
Summary: when I cancel a drag operation in Dolphin, Wayland session crashes and my sys...
Status: RESOLVED FIXED
Alias: None
Product: kwayland
Classification: Frameworks and Libraries
Component: server (show other bugs)
Version: 5.42.0
Platform: Other Linux
: NOR crash
Target Milestone: ---
Assignee: Martin Flöser
URL: https://phabricator.kde.org/D10142
Keywords: reproducible
Depends on:
Blocks:
 
Reported: 2018-01-19 19:22 UTC by Patrick Silva
Modified: 2018-02-25 13:16 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 5.44


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Silva 2018-01-19 19:22:20 UTC
Testing plasma 5.12 beta Wayland session on Arch Linux...

open dolphin and drag some folder/file
press ESC during drag operation... system freezes and goes to login screen 1 minute later.
Comment 1 Patrick Silva 2018-01-20 18:11:18 UTC
freeze/crash reproducible when I drag widgets from widgets explorer to my desktop or icons on my desktop.
Comment 2 Martin Flöser 2018-01-26 17:03:18 UTC
Backtrace of the crash. Moving to KWayland

#0  0x00007f0a59cf8696 in QScopedPointer<KWayland::Server::Resource::Private, QScopedPointerDeleter<KWayland::Server::Resource::Private> >::data() const (this=0x10)
    at /usr/include/x86_64-linux-gnu/qt5/QtCore/qscopedpointer.h:140
#1  0x00007f0a59d02158 in KWayland::Server::DataSourceInterface::d_func() const (this=0x0) at /home/martin/src/kf5/frameworks/kwayland/src/server/datasource_interface.cpp:161
#2  0x00007f0a59d0202f in KWayland::Server::DataSourceInterface::requestData(QString const&, int) (this=0x0, mimeType=..., fd=165)
    at /home/martin/src/kf5/frameworks/kwayland/src/server/datasource_interface.cpp:130
#3  0x00007f0a59d00bc1 in KWayland::Server::DataOfferInterface::Private::receive(QString const&, int) (this=0x555f826cb6d0, mimeType=..., fd=165)
    at /home/martin/src/kf5/frameworks/kwayland/src/server/dataoffer_interface.cpp:72
#4  0x00007f0a59d00b7f in KWayland::Server::DataOfferInterface::Private::receiveCallback(wl_client*, wl_resource*, char const*, int) (client=0x555f8270a620, resource=0x555f82715770, mimeType=0x555f81e0ee4c "text/uri-list", fd=165) at /home/martin/src/kf5/frameworks/kwayland/src/server/dataoffer_interface.cpp:67
#5  0x00007f0a4d98dfce in ffi_call_unix64 () at /usr/lib/x86_64-linux-gnu/libffi.so.6
#6  0x00007f0a4d98d93f in ffi_call () at /usr/lib/x86_64-linux-gnu/libffi.so.6
#7  0x00007f0a532dda3b in  () at /usr/lib/x86_64-linux-gnu/libwayland-server.so.0
#8  0x00007f0a532da27f in  () at /usr/lib/x86_64-linux-gnu/libwayland-server.so.0
#9  0x00007f0a532dbc12 in wl_event_loop_dispatch () at /usr/lib/x86_64-linux-gnu/libwayland-server.so.0
#10 0x00007f0a59d030c0 in KWayland::Server::Display::Private::dispatch() (this=0x555f810ebc20) at /home/martin/src/kf5/frameworks/kwayland/src/server/display.cpp:139
#11 0x00007f0a59d02d29 in KWayland::Server::Display::Private::<lambda()>::operator()(void) const (__closure=0x555f810ed000)
    at /home/martin/src/kf5/frameworks/kwayland/src/server/display.cpp:107
#12 0x00007f0a59d09286 in QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, KWayland::Server::Display::Private::installSocketNotifier()::<lambda()> >::call(KWayland::Server::Display::Private::<lambda()> &, void **) (f=..., arg=0x7ffeacf57d60) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:130
#13 0x00007f0a59d08cc7 in QtPrivate::Functor<KWayland::Server::Display::Private::installSocketNotifier()::<lambda()>, 0>::call<QtPrivate::List<>, void>(KWayland::Server::Display::Private::<lambda()> &, void *, void **) (f=..., arg=0x7ffeacf57d60) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:240
#14 0x00007f0a59d07859 in QtPrivate::QFunctorSlotObject<KWayland::Server::Display::Private::installSocketNotifier()::<lambda()>, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void **, bool *) (which=1, this_=0x555f810ecff0, r=0x555f810d0bd0, a=0x7ffeacf57d60, ret=0x0) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject_impl.h:168
#15 0x00007f0a57262e6f in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffeacf57d60, r=0x555f810d0bd0, this=0x555f810ecff0)
    at ../../include/QtCore/../../src/corelib/kernel/qobject_impl.h:101
#16 0x00007f0a57262e6f in QMetaObject::activate(QObject*, int, int, void**) (sender=sender@entry=0x555f810ef080, signalOffset=<optimized out>, local_signal_index=local_signal_index@entry=0,---Type <return> to continue, or q <return> to quit---
 argv=argv@entry=0x7ffeacf57d60) at kernel/qobject.cpp:3749
#17 0x00007f0a57263427 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (sender=sender@entry=0x555f810ef080, m=m@entry=0x7f0a5768cda0 <QSocketNotifier::staticMetaObject>, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7ffeacf57d60) at kernel/qobject.cpp:3628
#18 0x00007f0a5726f238 in QSocketNotifier::activated(int, QSocketNotifier::QPrivateSignal) (this=this@entry=0x555f810ef080, _t1=<optimized out>, _t2=...)
    at .moc/moc_qsocketnotifier.cpp:137
#19 0x00007f0a5726f602 in QSocketNotifier::event(QEvent*) (this=0x555f810ef080, e=0x7ffeacf57fd0) at kernel/qsocketnotifier.cpp:266
#20 0x00007f0a5815359c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#21 0x00007f0a5815ae64 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#22 0x00007f0a57234258 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=receiver@entry=0x555f810ef080, event=event@entry=0x7ffeacf57fd0)
    at kernel/qcoreapplication.cpp:1018
#23 0x00007f0a5728a188 in QCoreApplication::sendEvent(QObject*, QEvent*) (event=0x7ffeacf57fd0, receiver=<optimized out>)
    at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:233
#24 0x00007f0a5728a188 in QEventDispatcherUNIXPrivate::activateSocketNotifiers() (this=this@entry=0x555f8109ee60) at kernel/qeventdispatcher_unix.cpp:304
#25 0x00007f0a5728a808 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=<optimized out>, flags=...) at kernel/qeventdispatcher_unix.cpp:509
#26 0x00007f0a473f29dd in QUnixEventDispatcherQPA::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /opt/kf5/lib/x86_64-linux-gnu/plugins/platforms/KWinQpaPlugin.so
#27 0x00007f0a572322aa in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7ffeacf58180, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212
#28 0x00007f0a5723b214 in QCoreApplication::exec() () at kernel/qcoreapplication.cpp:1291
#29 0x0000555f7f584b8f in main(int, char**) (argc=4, argv=0x7ffeacf58a78) at /home/martin/src/kf5/kde/workspace/kwin/main_wayland.cpp:830
Comment 3 Martin Flöser 2018-01-27 13:10:46 UTC
So this turned out to be a nasty little beast.

Qt destroys the drag datasource on escape. But that's something KWayland didn't handle at all and didn't expect to happen. So internally the drag and drop continued and when releasing the mouse button this was interpreted as a finished drag and drop operation. The drop target started to request the data from the (now destroyed) datasource. And that triggered the crash.

I reworked the code to properly cancel the drag operation when the datasource is destroyed.
Comment 4 Martin Flöser 2018-01-27 13:17:13 UTC
Patch at https://phabricator.kde.org/D10142
Comment 5 Markus Rathgeb 2018-02-15 20:32:08 UTC
*** Bug 390341 has been marked as a duplicate of this bug. ***
Comment 6 Martin Flöser 2018-02-25 13:16:00 UTC
Git commit 2dfe16d774c79ede20ac9439f66459b6a8026525 by Martin Flöser.
Committed on 25/02/2018 at 13:14.
Pushed by graesslin into branch 'master'.

[server] Properly handle the situation when the DataSource for a drag gets destroyed

Summary:
This addresses the following situation:
1. Start drag on a QtWayland based window
2. Press escape
3. Release mouse

-> this results in a crash. The main reason for this is that QtWayland
destroys the DataSource in step 2 and KWayland did not expect this at
all. The drag and drop operation continued and results in step 3 in the
drag target to request data from the no longer existing DataSource.

This change addresses the root of the problem by cancelling the drag
operation when the DataSource gets destroyed.
FIXED-IN: 5.44

Test Plan:
New test case exposing the problem and manual testing with
kwin_wayland and dolphin (based on bug report)

Reviewers: #frameworks, #kwin, #plasma

Subscribers: plasma-devel

Tags: #frameworks, #plasma

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

M  +95   -0    autotests/client/test_drag_drop.cpp
M  +7    -2    src/server/datadevice_interface.cpp
M  +16   -1    src/server/seat_interface.cpp
M  +1    -0    src/server/seat_interface_p.h

https://commits.kde.org/kwayland/2dfe16d774c79ede20ac9439f66459b6a8026525