Dolphin 15.12
KDE Frameworks 5.17.0
- Qt 5.5.0 (built against 5.5.0)
- The *xcb*
windowing system
Moving or copying operations in split mode - drag item to other window and drop - results in Dolphin closing down and the “We are sorry, Dolphin closed unexpectedly…” message makes its unwelcome appearance.
I tried two of the workarounds mentioned on these forums:
deleting ~/.local/share/kactivitymanagerd/ - from a remote location while neither KDE or Dolphin were active
switching Appearance>Application Style>Widget Style from breeze to oxygen
Over the last three hours I have logged out, restarted, searched bug reports. I can’t see any other solutions.
Are there any other solutions apart from the obvious - don’t use Dolphin for moving files.
I mean I can use rsync at the command line but that’s for BIG files - two pane drag and dropping gets my vote most times.
I use Konqueror as a file manager too. Dolphin has grown on me over the years
Can’t reproduce your error. Is it when you start dolphine from konsole you get the error message “We are sorry, Dolphin closed unexpectedly…” or does it give any more info?
I’m not experiencing this either, but I’m running Leap as a guest OS in VirtualBox, and this may well be related to to the graphics hardware of the affected system(s).
I can reproduce it every single time. The application Dolphin is started from the menu not konsole.
The error message after crashing is the KDE developers standard grey box that gives one the opportunity to report a bug - I might not have been clear about that. I am sure there is not a kde user 0f 3,4, or 5 who has not seen that error box more than once in his or her lifetime.
I can’t send a screenshot as I have just discovered the absence of ksnapshot on my installation.
Here is the output of the error box’s Developer tab
Application: Dolphin (dolphin), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fb7de1e4800 (LWP 2035))]
Thread 3 (Thread 0x7fb7c575b700 (LWP 2036)):
#0 0x00007fb7dda7fc1d in poll () from /lib64/libc.so.6
#1 0x00007fb7d09eb422 in ?? () from /usr/lib64/libxcb.so.1
#2 0x00007fb7d09ed00f in xcb_wait_for_event () from /usr/lib64/libxcb.so.1
#3 0x00007fb7c80e6c29 in ?? () from /usr/lib64/libQt5XcbQpa.so.5
#4 0x00007fb7d7ba655f in ?? () from /usr/lib64/libQt5Core.so.5
#5 0x00007fb7d36580a4 in start_thread () from /lib64/libpthread.so.0
#6 0x00007fb7dda8804d in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7fb7ba97f700 (LWP 2038)):
#0 0x00007fb7dda7fc1d in poll () from /lib64/libc.so.6
#1 0x00007fb7d2ad2e64 in ?? () from /usr/lib64/libglib-2.0.so.0
#2 0x00007fb7d2ad2f7c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3 0x00007fb7d7dd7a5b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#4 0x00007fb7d7d7ea63 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#5 0x00007fb7d7ba184a in QThread::exec() () from /usr/lib64/libQt5Core.so.5
#6 0x00007fb7d7ba655f in ?? () from /usr/lib64/libQt5Core.so.5
#7 0x00007fb7d36580a4 in start_thread () from /lib64/libpthread.so.0
#8 0x00007fb7dda8804d in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7fb7de1e4800 (LWP 2035)):
[KCrash Handler]
#6 0x00007fb7b92f5347 in ?? () from /usr/lib64/qt5/plugins/kf5/kio_dnd/extracthere.so
#7 0x00007fb7dc364846 in ?? () from /usr/lib64/libKF5KIOWidgets.so.5
#8 0x00007fb7dc3655bf in ?? () from /usr/lib64/libKF5KIOWidgets.so.5
#9 0x00007fb7dc365d5f in ?? () from /usr/lib64/libKF5KIOWidgets.so.5
#10 0x00007fb7dc366219 in ?? () from /usr/lib64/libKF5KIOWidgets.so.5
#11 0x00007fb7dc366490 in ?? () from /usr/lib64/libKF5KIOWidgets.so.5
#12 0x00007fb7d7db1796 in QObject::event(QEvent*) () from /usr/lib64/libQt5Core.so.5
#13 0x00007fb7d8ef5e8c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#14 0x00007fb7d8efacd8 in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#15 0x00007fb7d7d80ba5 in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/libQt5Core.so.5
#16 0x00007fb7d7d82d67 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib64/libQt5Core.so.5
#17 0x00007fb7d7dd85c3 in ?? () from /usr/lib64/libQt5Core.so.5
#18 0x00007fb7d2ad2c84 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#19 0x00007fb7d2ad2ed8 in ?? () from /usr/lib64/libglib-2.0.so.0
#20 0x00007fb7d2ad2f7c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#21 0x00007fb7d7dd7a3c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#22 0x00007fb7d7d7ea63 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#23 0x00007fb7d7d865d6 in QCoreApplication::exec() () from /usr/lib64/libQt5Core.so.5
#24 0x00007fb7dddaa5f1 in kdemain () from /usr/lib64/libkdeinit5_dolphin.so
#25 0x00007fb7dd9c4b05 in __libc_start_main () from /lib64/libc.so.6
#26 0x00000000004007ee in _start ()
There is a report bug button on the KDE developers “we are sorry box” and I think I’ll press that and hope for the best.
I was just hoping that someone else here might have experienced dolphin split mode drag and drop crashing.
As I said I thought I might use the developers’ own error reporting box to send the backtrace report.
During the process the reporter tests whether debugging symbols are present and if not offers to install them.
I allowed the app to do that and was presented with a terminal window and a request for root’s password.
I watched the reporter go into action and download and install the debugging symbols packages - 2 in total iirc.
On with the window by window reporter next, next - crash! The crash reporter crashed.
Despite being unwell with a raging sore throat I burst out laughing.
Anyway I opened Dolphin performed the “how I make dolphin crash manoeuvre” and waited for the crash reporter to pop up up again.
It did, I filled in the report, only one minor hitch this time as it asked me for my kde bug log-in and password.
I had forgotten them and had to open prefs in Firefox and retrieve them from saved passwords.
Logged in, accepted, sent the report, pressed finish where I was promised I would be taken straight to the page where I could view my bug report in all its glory.
Can you see where I’m going with this? It did not take me to my new bug report. I gave it a few minutes and then did a kde bug report search for new bugs - mine wasn’t there - so I’ll probably enter it by hand once I stop laughing.
While I was on the KDE Bug site I discovered Dolphin split view pane crashes going back to 2008 so it isn’t a new thing. Some folks could reproduce it and some couldn’t. There were vague noises such as a broken handler deep within Qt; some mentioned having heard of preview mode being enabled at the same time as split view or a certain type of file or folder.
The difference I have in this install is the existence of the extra repos - extra; frameworks; applications. I do not have them enabled on my other leap 42.1 install and I do not experience Dolphin crashing.
I’m off - not immediately - to manually enter the bug on the site.
solstice greetings (its already the 21st where I live)
Got the bug report done. https://bugs.kde.org/show_bug.cgi?id=356976
Found an interesting crash recorder I hadn’t heard of while brosing the KDE Bugsite.
It is called valgrind here is the output of my dolphin crashing!
==2432== Memcheck, a memory error detector
==2432== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==2432== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==2432== Command: dolphin
==2432==
==2432== Invalid read of size 4
==2432== at 0x5EC2E50: KCrash::setCrashHandler(void (*)(int)) (in /usr/lib64/libKF5Crash.so.5.17.0)
==2432== by 0x5EC3B7B: KCrash::setDrKonqiEnabled(bool) (in /usr/lib64/libKF5Crash.so.5.17.0)
==2432== by 0x5EC4399: KCrash::initialize() (in /usr/lib64/libKF5Crash.so.5.17.0)
==2432== by 0xAF05FBF: QCoreApplication::init() (in /usr/lib64/libQt5Core.so.5.5.0)
==2432== by 0xAF062F5: QCoreApplication::QCoreApplication(QCoreApplicationPrivate&) (in /usr/lib64/libQt5Core.so.5.5.0)
==2432== by 0xA1B8D98: QGuiApplication::QGuiApplication(QGuiApplicationPrivate&) (in /usr/lib64/libQt5Gui.so.5.5.0)
==2432== by 0x99A51BC: QApplication::QApplication(int&, char**, int) (in /usr/lib64/libQt5Widgets.so.5.5.0)
==2432== by 0x4E93CBE: kdemain (main.cpp:40)
==2432== by 0x5129B04: (below main) (in /lib64/libc-2.19.so)
==2432== Address 0x198c0d10 is 0 bytes inside a block of size 3 alloc'd
==2432== at 0x4C29110: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==2432== by 0x5EC2DE9: KCrash::setCrashHandler(void (*)(int)) (in /usr/lib64/libKF5Crash.so.5.17.0)
==2432== by 0x5EC3B7B: KCrash::setDrKonqiEnabled(bool) (in /usr/lib64/libKF5Crash.so.5.17.0)
==2432== by 0x5EC4399: KCrash::initialize() (in /usr/lib64/libKF5Crash.so.5.17.0)
==2432== by 0xAF05FBF: QCoreApplication::init() (in /usr/lib64/libQt5Core.so.5.5.0)
==2432== by 0xAF062F5: QCoreApplication::QCoreApplication(QCoreApplicationPrivate&) (in /usr/lib64/libQt5Core.so.5.5.0)
==2432== by 0xA1B8D98: QGuiApplication::QGuiApplication(QGuiApplicationPrivate&) (in /usr/lib64/libQt5Gui.so.5.5.0)
==2432== by 0x99A51BC: QApplication::QApplication(int&, char**, int) (in /usr/lib64/libQt5Widgets.so.5.5.0)
==2432== by 0x4E93CBE: kdemain (main.cpp:40)
==2432== by 0x5129B04: (below main) (in /lib64/libc-2.19.so)
==2432==
Unable to update the static FcBlanks: 0x0600
Unable to update the static FcBlanks: 0x0601
Unable to update the static FcBlanks: 0x0602
Unable to update the static FcBlanks: 0x0603
Unable to update the static FcBlanks: 0x06dd
Unable to update the static FcBlanks: 0x070f
Unable to update the static FcBlanks: 0x2028
Unable to update the static FcBlanks: 0x2029
Unable to update the static FcBlanks: 0xfff9
Unable to update the static FcBlanks: 0xfffa
Unable to update the static FcBlanks: 0xfffb
==2432== Warning: set address range perms: large range 0x3a048000, 0x17a048000) (defined)
==2432== Invalid read of size 4
==2432== at 0x28FC2347: ??? (in /usr/lib64/qt5/plugins/kf5/kio_dnd/extracthere.so)
==2432== by 0x694C845: KIO::DropJobPrivate::addPluginActions(QMenu*, KFileItemListProperties const&) (dropjob.cpp:299)
==2432== by 0x694D5BE: KIO::DropJobPrivate::fillPopupMenu(QMenu*) (dropjob.cpp:283)
==2432== by 0x694DD5E: KIO::DropJobPrivate::handleCopyToDirectory() (dropjob.cpp:343)
==2432== by 0x694E218: KIO::DropJobPrivate::slotStart() (dropjob.cpp:145)
==2432== by 0x694E48F: KIO::DropJob::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_dropjob.cpp:92)
==2432== by 0xAF32795: QObject::event(QEvent*) (in /usr/lib64/libQt5Core.so.5.5.0)
==2432== by 0x99A2E8B: QApplicationPrivate::notify_helper(QObject*, QEvent*) (in /usr/lib64/libQt5Widgets.so.5.5.0)
==2432== by 0x99A7CD7: QApplication::notify(QObject*, QEvent*) (in /usr/lib64/libQt5Widgets.so.5.5.0)
==2432== by 0xAF01BA4: QCoreApplication::notifyInternal(QObject*, QEvent*) (in /usr/lib64/libQt5Core.so.5.5.0)
==2432== by 0xAF03D66: QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (in /usr/lib64/libQt5Core.so.5.5.0)
==2432== by 0xAF595C2: ??? (in /usr/lib64/libQt5Core.so.5.5.0)
==2432== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==2432==
KCrash: Application 'dolphin' crashing...
KCrash: Attempting to start /usr/lib64/libexec/drkonqi from kdeinit
==2432==
==2432== HEAP SUMMARY:
==2432== in use at exit: 12,899,790 bytes in 85,996 blocks
==2432== total heap usage: 1,345,632 allocs, 1,259,636 frees, 2,183,424,402 bytes allocated
==2432==
==2432== LEAK SUMMARY:
==2432== definitely lost: 2,442 bytes in 12 blocks
==2432== indirectly lost: 4,513 bytes in 132 blocks
==2432== possibly lost: 1,360,360 bytes in 318 blocks
==2432== still reachable: 11,532,475 bytes in 85,534 blocks
==2432== suppressed: 0 bytes in 0 blocks
==2432== Rerun with --leak-check=full to see details of leaked memory
==2432==
==2432== For counts of detected and suppressed errors, rerun with: -v
==2432== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 3 from 1)
dolphin4 is the old KDE4 version (mainly still included so that Konqueror works as file manager), while you are using the KF5 based dolphin. So that update can’t have an impact of course.
So, as a workaround to avoid the crashes you could use dolphin4 or Konqueror…
Btw, I never experienced such a crash here either.
But then, I’m on 13.2 and use Qt 5.5.1. A Qt update for Leap 42.1 is running at the moment, maybe that would help…
One thing I would recommend though to make sure that you don’t have a mixture of packages in different versions installed:
# zypper dup --from 1
Loading repository data...
Reading installed packages...
Computing distribution upgrade...
Problem: nothing provides libmarblewidget-qt5.so.23()(64bit) needed by libKF5KGeoMap10_0_0-15.12.0-23.2.x86_64
Solution 1: Following actions will be done:
deinstallation of libkgeomap2-15.08.3-21.1.x86_64
deinstallation of libkgeomap-15.08.3-21.1.x86_64
deinstallation of kipi-plugins-geolocation-4.13.0-2.3.x86_64
deinstallation of digikam-4.13.0-2.3.x86_64
deinstallation of digikam-lang-4.13.0-2.3.noarch
Solution 2: keep obsolete libkgeomap-15.08.3-21.1.x86_64
Solution 3: break libKF5KGeoMap10_0_0-15.12.0-23.2.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/c] (c):
As usual I do not know what to do. I’m pretty sure I wouldn’t want to lose digikam.
Choose Solution 2, “keep the obsolete libkgeomap”…
There seems to be an inconsistency in the repo, and using both KDE:Extra and KDE:Applications on Leap is not really supported…
As you are using devel repos for Factory, such things can happen.
And incomplete upgrades can of course cause the strangest problems.
You could just as well remove the KDE:Applications repo though and switch back to the standard versions, KDE Applications 15.12.0 will be released as official update for Leap anyway.
Well blow me down, there was me thinking since the repos extra;applications;frameworks 5 are all on the wiki as official repos I figured they would be just fine.
Ah well. I removed the applications repo for starters and zypper reffed then zypper upped. This was the result:
zypper up
Loading repository data...
Reading installed packages...
The following 43 package updates will NOT be installed:
amarok amarok-lang ark choqok cln digikam digikam-lang dragonplayer gstreamer-plugins-qt kdeartwork4-screensaver kdeartwork4-wallpapers kdeartwork4-wallpapers-weather kgpg kipi-plugins
kipi-plugins-acquireimage kipi-plugins-geolocation kipi-plugins-lang konversation konversation-lang ktorrent ktorrent-lang lensfun-data libepub0 libhdf5-10 libhdf5_hl10 libkdcraw23 libkface3
libkipi11 libksane0 liblensfun0 libloudmouth-1-0 libopencv2_4 libpackagekitqt5-0 libqalculate5 libtag-extras1 libtelepathy-qt4-2 moodbar python3-setuptools skanlite skanlite-doc skanlite-lang
susehelp susehelp_en
Nothing to do.
I might ad that I did not proceed with zypper dup --from 1 in the previous post. when I saw your response I had already cancelled the transation and this morning I removed the applications repo.
I’m beginning to wonder if I shouldn’t remove extra and Frameworks 5 as well, although extra provides packages like acetone that aren’t in the official repos. There shouldn’t be conflicts from extra since they aren’t provided anywhere else. No? Wrong again? Bad assumptions?
Zypper up only updates when it finds packages with higher version numbers in the vendors repo then what you he installed . Simply removing repos (vendors) does nothing to remove the packages. You need to do dup to revert things back to where they should be, as wolfi told you.
They are kind of official, but those are devel repos for Factory/Tumbleweed and always contain the latest versions without prior testing.
So there can be problems at times. Although as it only gets stable upstream versions, it should be safe to use.
But it is recommended that you do a full switch to that repo. Otherwise you could/will end up with a mixture of package versions that might not fit together.
Ah well. I removed the applications repo for starters and zypper reffed then zypper upped. This was the result:
I might ad that I did not proceed with zypper dup --from 1 in the previous post. when I saw your response I had already cancelled the transation and this morning I removed the applications repo.
Adding/removing repos will not change your installed packages. And as gogalthorpe wrote already, “zypper up” will not switch packages to versions from a different repo either.
You need to switch them manually.
Either look in YaST->Software Management for packages marked in red and “Upgrade Unconditionally” or switch them via the “Versions” tab, or run “zypper dup” but that might be problematic too if you have many repos.
For further advise, please post your repo list:
zypper lr -d
I’m beginning to wonder if I shouldn’t remove extra and Frameworks 5 as well, although extra provides packages like acetone that aren’t in the official repos. There shouldn’t be conflicts from extra since they aren’t provided anywhere else. No? Wrong again? Bad assumptions?
KDE:Extra shouldn’t cause problems, but the same applies there: it is the devel repo for Factory and always gets the latest versions without prior testing. But it also contains packages not included in the distribution.
It should be safe to use though, and definitely should not cause problems with dolphin…
repos are exactly the same as in post 1 of this thread - with the exception of Applications which I have now removed.
All the “extra” repos except the repo named extra were switched using Yast at the time of their addition.
It’s not your fault you didn’t know that - I didn’t tell you about the switch. Call it an information omission if you will!
So I’m dupped and done.
Back to “normal” - which is to say that dolphin version 15.08.3 now drags and drops in split mode without the crashing behaviour demonstrated by 15.12.x
If I ever decide to add a repo how about yours, wolfi?