SUMMARY The system hangs when a file is dragged from Dolphin to the desktop. It looks as if the file is cached in memory before the menu to select copy/move etc is displayed. This is especially problematic as extremely large files can cause the system to hang for multiple minutes. This does not occur when dragging from one Dolphin session to another as the copy/move menu is displayed right away. STEPS TO REPRODUCE 1. Drag a large file from Dolphin to the desktop without holding any modifier keys. My test file is 100 GB. OBSERVED RESULT System hangs until the file has been transferred completely and then the menu is shown to select copy/move. While system is hung, cached memory increases until full. Not sure what is happening if file that is being transferred is larger than free RAM as hard drive does not indicate any activity. EXPECTED RESULT When a file is dragged to the desktop, display the menu to select copy/move before file is transferred. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.1.1 KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7
> My test file is 100 GB. OMG I think what's going on is that the file is being opened or at least stat'ed to check its MIME type to see if it's droppable, and this is non-ideal for huge files.
I can reproduce it with a 5GB file: 1 In dolphin select file 2 start dragging 3 hold ctrl 4 release on desktop System (plasmashell) hangs for a few seconds, before displaying the drop menu. This seems not to be be as slow once this is done twice in a row, hinting at a disk cache. I got this stack trace during the hang : Thread 1 "plasmashell" received signal SIGINT, Interrupt. __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x55a8518e05f0) at ./nptl/futex-internal.c:57 57 ./nptl/futex-internal.c: Aucun fichier ou dossier de ce type. (gdb) bt #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x55a8518e05f0) at ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55a8518e05f0) at ./nptl/futex-internal.c:87 #2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x55a8518e05f0, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x00007f290108f338 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55a8518e05a0, cond=0x55a8518e05c8) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_wait (cond=0x55a8518e05c8, mutex=0x55a8518e05a0) at ./nptl/pthread_cond_wait.c:627 #5 0x00007f29018d2b1b in QWaitConditionPrivate::wait(QDeadlineTimer) (deadline=..., this=0x55a8518e05a0) at thread/qwaitcondition_unix.cpp:146 #6 QWaitCondition::wait(QMutex*, QDeadlineTimer) (this=this@entry=0x55a84ec16828, mutex=mutex@entry=0x55a84ec16808, deadline=...) at thread/qwaitcondition_unix.cpp:225 #7 0x00007f29018cc919 in QThread::wait(QDeadlineTimer) (this=<optimized out>, deadline=...) at ../../include/QtCore/../../src/corelib/thread/qmutex.h:270 #8 0x00007f28ffc7b98c in () at /lib/x86_64-linux-gnu/libKF5KIOCore.so.5 #9 0x00007f28ffc7b9ed in () at /lib/x86_64-linux-gnu/libKF5KIOCore.so.5 #10 0x00007f2901ae55fe in QObjectPrivate::deleteChildren() (this=this@entry=0x55a84fd9a580) at kernel/qobject.cpp:2137 #11 0x00007f2901af1744 in QObject::~QObject() (this=<optimized out>, __in_chrg=<optimized out>) at kernel/qobject.cpp:1115 --Type <RET> for more, q to quit, c to continue without paging-- #12 0x00007f28ffbfed2c in KIO::Slave::deref() () at /lib/x86_64-linux-gnu/libKF5KIOCore.so.5 #13 0x00007f2901af36ff in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffec45b7e20, r=0x55a84cd1b1f0, this=0x55a8518cfd20) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #14 doActivate<false>(QObject*, int, void**) (sender=0x55a850f32930, signal_index=3, argv=0x7ffec45b7e20) at kernel/qobject.cpp:3919 #15 0x00007f2901ae7b30 in QObject::event(QEvent*) (this=0x55a850f32930, e=0x55a84fda7810) at kernel/qobject.cpp:1347 #16 0x00007f290276bf32 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #17 0x00007f2901abae38 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x55a850f32930, event=0x55a84fda7810) at kernel/qcoreapplication.cpp:1064 #18 0x00007f2901abdeb1 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (receiver=0x0, event_type=0, data=0x55a84b507ec0) at kernel/qcoreapplication.cpp:1821 #19 0x00007f2901b15427 in postEventSourceDispatch(GSource*, GSourceFunc, gpointer) (s=0x55a84b54c640) at kernel/qeventdispatcher_glib.cpp:277 #20 0x00007f28ffe734f9 in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #21 0x00007f28ffec8228 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #22 0x00007f28ffe70cb0 in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #23 0x00007f2901b14aea in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x55a84b5510d0, flags=...) at kernel/qeventdispatcher_glib.cpp:423 #24 0x00007f2901ab97cb in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7ffec45b8210, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69 #25 0x00007f2901ac1c2a in QCoreApplication::exec() () at ../../include/QtCore/../../src/corelib/global/qflags.h:121 #26 0x000055a84ad6a567 in () #27 0x00007f2901023510 in __libc_start_call_main (main=main@entry=0x55a84ad696b0, argc=argc@entry=1, argv=argv@entry=0x7ffec45b84d8) at ../sysdeps/nptl/libc_start_call_main.h:58 #28 0x00007f29010235c9 in __libc_start_main_impl (main=0x55a84ad696b0, argc=1, argv=0x7ffec45b84d8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffec45b84c8) at ../csu/libc-start.c:381 #29 0x000055a84ad6a685 in () It seems to suggest a sort of memory leak causing Qt not to free memory. Or maybe that's called in a loop. The event in #15 in the stacktrace is : (gdb) p *e $3 = {_vptr.QEvent = 0x7f2901d59e98 <vtable for QMetaCallEvent+16>, static staticMetaObject = {d = { superdata = {direct = 0x0}, stringdata = 0x7f2901c86100 <qt_meta_stringdata_QEvent>, data = 0x7f2901c85b40 <qt_meta_data_QEvent>, static_metacall = 0x0, relatedMetaObjects = 0x0, extradata = 0x0}}, d = 0x0, t = 43, posted = 0, spont = 0, m_accept = 1, reserved = 0} With t (43) == QEvent::MetaCall
I don't reproduce it in Plasma 6.1.4. I would welcome a second confirmation.
How about you, kroot001@gmail.com? Are you still able to reproduce it with Plasma 6.1.4 or later? Thanks for checking!
(In reply to Nate Graham from comment #4) > How about you, kroot001@gmail.com? Are you still able to reproduce it with > Plasma 6.1.4 or later? Thanks for checking! Just tested this on Plasma 6.1.5 and can no longer reproduce the issue. Looks like this can be closed!
Wonderful!