Here is the stack trace. It might be a bug in qtwayland, but I'm not sure what dolphin is doing to cause a crash No stack. Starting program: /opt/bin/dolphin [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". [New Thread 0xb2e90b40 (LWP 3527)] [New Thread 0xb1369b40 (LWP 3532)] Program received signal SIGSEGV, Segmentation fault. 0xb5fa8d9a in QMimeData::hasText() const () from /opt/lib/libQt5Core.so.5 #0 0xb5fa8d9a in QMimeData::hasText() const () from /opt/lib/libQt5Core.so.5 No symbol table info available. #1 0xb7529a3e in KIO::canPasteMimeData(QMimeData const*) () from /opt/lib/i386-linux-gnu/libKF5KIOWidgets.so.5 No symbol table info available. #2 0xb7d18158 in KonqOperations::pasteInfo(KUrl const&) () from /opt/lib/i386-linux-gnu/libkonq.so.SOVERSION No symbol table info available. #3 0xb7c791a5 in DolphinView::pasteInfo() const () from /opt/lib/i386-linux-gnu/libdolphinprivate.so.SOVERSION No symbol table info available. #4 0xb7f3cb93 in DolphinMainWindow::updatePasteAction() () from /opt/lib/i386-linux-gnu/libkdeinit4_dolphin.so No symbol table info available. #5 0xb7f44ba4 in DolphinMainWindow::updateEditActions() () from /opt/lib/i386-linux-gnu/libkdeinit4_dolphin.so No symbol table info available. #6 0xb7f39e08 in DolphinMainWindow::DolphinMainWindow() () from /opt/lib/i386-linux-gnu/libkdeinit4_dolphin.so No symbol table info available. #7 0xb7f369d0 in DolphinApplication::DolphinApplication() () from /opt/lib/i386-linux-gnu/libkdeinit4_dolphin.so No symbol table info available. #8 0xb7f5ea1b in kdemain () from /opt/lib/i386-linux-gnu/libkdeinit4_dolphin.so No symbol table info available. #9 0x080486c2 in main () No symbol table info available. A debugging session is active. Inferior 1 [process 3518] will be killed. Quit anyway? (y or n) Reproducible: Always Steps to Reproduce: start dolphin under wayland
Forgot to add that It appears to be something with the clipboard
Thanks for the bug report! (In reply to comment #1) > Forgot to add that It appears to be something with the clipboard Yes. To be precise, the lib/konq part of kde-baseapps (which has no corresponding product at bugs.kde.org) tries to investigate the clipboard contents in order to determine the text for the "Paste" action. Maybe the return value of QApplication::clipboard() is 0, but it's hard to tell because your backtrace lacks all important details, such as line numbers and function arguments. Please consider installing debug packages for Qt5 and all of KDE - you really should always try to provide a detailed backtrace when you submit a bug report. Even more so if the bug cannot be reproduced by the people whom you send the reports to - I guess I'm not the only one who will not be able to reproduce Wayland issues in the near future. I cannot really see how getting the MIME data from the clipboard and investigating it can be a bug in KDE, so you might want to report this to Qt indeed (ideally with a Qt-only testcase). If you think that I'm wrong, and you can provide any evidence that there is a bug in KDE, please let us know. Thanks for your help.
Created attachment 86931 [details] Stack Trace of Wayland Dolphin Crash I hope this is enough info, and I don't have to rebuild all of qt5...
Thanks. It seems that QApplication::clipboard() really returns 0 then. IMHO, this is definitely a bug in Qt because the API docs do not say at all that the return value might be 0. It's something that we can work around though by adding a null-pointer check in lib/konq. This will only fix the crash though - pasting files will most likely not work due to the Qt issue. That is, unless the return value is 0 only if the clipboard is empty on Wayland - could you try to copy something (like a file from FolderView or some text from a text editor) before you start Dolphin and try if that works around the crash? If Dolphin still crashes then, then it seems that your Qt/Wayland installation has no support for using the clipboard at all.
(In reply to comment #4) > Thanks. It seems that QApplication::clipboard() really returns 0 then. I meant that QApplication::clipboard()->mimeData() returns 0.
Git commit 7828b057da0491f1b08bfaec681067e195d7b6ca by Frank Reininghaus. Committed on 01/06/2014 at 12:44. Pushed by freininghaus into branch 'master'. Do not crash if QApplication::clipboard()->mimeData() is a null pointer According to a recent bug report, this can happen on Wayland. The root cause of the problem might be a problem in Qt's Wayland support itself, but this patch at least prevents that Dolphin and other applications which check the clipboard state to determine the text of the paste action crash on startup. REVIEW: 118450 M +11 -2 lib/konq/konq_operations.cpp http://commits.kde.org/kde-baseapps/7828b057da0491f1b08bfaec681067e195d7b6ca
Created attachment 86955 [details] 2nd wayland dophin crash
Hi. unfortunantly it sees there is another library that is doing the same thing when I try to run Dolphin on Wayland I attached the stack trace
Thanks for testing it. We can work around this crash as well, but I would still be interested in the answer to my question from comment 4: does it also crash if you cut/copy something from FolderView, a text editor or something else before you open Dolphin? If that is the case, then the root cause of these crashes is that Qt has no clipboard support in Wayland yet, and then you will not be able to use cut/copy/paste, even if we add workarounds for the crash.
(In reply to comment #9) > Thanks for testing it. We can work around this crash as well, but I would > still be interested in the answer to my question from comment 4: does it > also crash if you cut/copy something from FolderView, a text editor or > something else before you open Dolphin? > > If that is the case, then the root cause of these crashes is that Qt has no > clipboard support in Wayland yet, and then you will not be able to use > cut/copy/paste, even if we add workarounds for the crash. I tried it. It still crashes...
(In reply to comment #10) > I tried it. It still crashes... IMHO, this confirmed that the crash is due to QApplication::clipboard()->mimeData() always returning 0, no matter what the clipboard contents are, i.e., that it is a Qt bug. But I see that you reopened this report, so it seems that you do not quite agree with me ;-) Since more people might start testing stuff on Wayland soon, and I don't know when clipboard support will be fixed, it probably makes sense to add a workaround - copy&paste not working is probably less annoying than a crash on startup: https://git.reviewboard.kde.org/r/118649/ Please do check if the issue is still present in the latest Qt5 git checkout though, and report the bug to Qt if that is the case.
Git commit cde87d91c2c9865268004e2d77deebad9d9c833e by Frank Reininghaus. Committed on 12/06/2014 at 06:37. Pushed by freininghaus into branch 'master'. Do not crash if QApplication::clipboard()->mimeData() is a null pointer This removes the remaining unchecked accesses to the clipboard mime data after commit 7828b057da0491f1b08bfaec681067e195d7b6ca. According to a bug report, it can be a null pointer on Wayland. REVIEW: 118649 M +2 -3 dolphin/src/dolphincontextmenu.cpp M +8 -0 dolphin/src/kitemviews/private/kfileitemclipboard.cpp M +4 -15 dolphin/src/panels/folders/treeviewcontextmenu.cpp http://commits.kde.org/kde-baseapps/cde87d91c2c9865268004e2d77deebad9d9c833e
Thanks! It works!
I'm glad that it works now, thanks for lettings us know!