| Summary: | Digikam crashes immediately upon trying to access Configuration panel (under Wayland) | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | martinlaird |
| Component: | Portability-Runtime | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | caulier.gilles, finnh.spam, krinpaus, metzpinguin |
| Priority: | NOR | ||
| Version: | 8.4.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=492191 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | 8.5.0 | ||
| Attachments: |
Requested GDB-backtrace
Updated Stacktrace after potential fix digikam log Current window size |
||
|
Description
martinlaird
2024-10-18 13:48:17 UTC
Maik, In the backtrace we can see : #4 ___pthread_cond_wait (cond=0x7fff729fe9e0, mutex=<optimized out>) at pthread_cond_wait.c:618 No locals. #5 0x00007fffede889ae in base::ConditionVariable::Wait () at ./../../../../../qtwebengine/src/3rdparty/chromium/base/synchronization/condition_variable_posix.cc:105 No locals. #6 0x00007fffedeb6b48 in base::WaitableEvent::TimedWaitImpl () at ./../../../../../qtwebengine/src/3rdparty/chromium/base/synchronization/waitable_event_posix.cc:193 No locals. #7 0x00007fffede35d4b in base::WaitableEvent::TimedWait () at ./../../../../../qtwebengine/src/3rdparty/chromium/base/synchronization/waitable_event.cc:39 No locals. #8 0x00007fffeddeaa8d in base::MessagePumpDefault::Run () at ./../../../../../qtwebengine/src/3rdparty/chromium/base/message_loop/message_pump_default.cc:56 Sounds like a QtWebEngine crash. Right ? Gilles Hi Gilles, the question is whether it actually crashes in QWebEngine, the backtrace looks strange. I also see NVidia in the backtrace. I didn't know that QWebEngine was used in the setup dialog. We already have a bug report in connection with the setup dialog under Wayland (flickering problems). But there's nothing special about the setup dialog. I can't reproduce the crash here under Wayland and openSUSE either. Maik No there is no webengine in the setup dialog, but perhaps the crash appears when the dialog must be show on the screen and the webengine trace is just a side effect. A real GDB backtrace will help here... Gilles It's my first time using gdb or submitting a bug report like this. I followed the guide at https://wiki.archlinux.org/title/Debugging/Getting_traces#Getting_the_trace. Unsure what I might have missed but happy to try again if there's anything else I can do. Appreciate you guys looking into this so quickly. Up until this week Wayland has been too unstable for me to use, but as of now this is the only issue I'm having with it. Git commit 05d03762a74032b42cb11c587c3ec14fa87d066b by Maik Qualmann. Committed on 19/10/2024 at 18:22. Pushed by mqualmann into branch 'master'. try an additional check on wayland M +1 -1 core/libs/dimg/filters/icc/iccsettings_p_desktop.cpp https://invent.kde.org/graphics/digikam/-/commit/05d03762a74032b42cb11c587c3ec14fa87d066b Just cloned the repo and created a local build from dev. The error still persist: ``` wp_linux_drm_syncobj_surface_v1#69: error 4: explicit sync is used, but no acquire point is set qt.qpa.wayland: eglSwapBuffers failed with 0x3000, surface: 0x59d8065b89a0 qt.qpa.wayland: eglSwapBuffers failed with 0x3000, surface: 0x59d8065b89a0 ``` My system has the following specs: Operating System: EndeavourOS KDE Plasma Version: 6.2.2 KDE Frameworks Version: 6.7.0 Qt Version: 6.8.0 Kernel Version: 6.11.5-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 31,3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3070/PCIe/SSE2 Manufacturer: Micro-Star International Co., Ltd. System Version: 6.0 I see a bug report for KInfocenter with the same error message, probably a Qt or driver problem. Can you please create a GDB backtrace. Maik I tried the following steps: 1. gdb digikam 2. (gdb) run 3. reproduce the bug. But I did not get any additional output to the one I posted before. If you need more debug logs or something like that, I would be glad if you could provide some instructions. After the crash you have to type "bt" + enter to output the backtrace. Maik Created attachment 175345 [details]
Requested GDB-backtrace
It crashes really deep inside Qt, in the QtWaylandClient. I'm just wondering why in the setup dialog. We change the Windows flags, I'll undo this change for testing purposes. Maik Git commit 5dc2c7f78cbd99d9af506f3c96a0f61d7d0954c5 by Maik Qualmann. Committed on 29/10/2024 at 21:31. Pushed by mqualmann into branch 'master'. do not change the window flags from the setup dialog M +2 -1 core/utilities/setup/setup.cpp https://invent.kde.org/graphics/digikam/-/commit/5dc2c7f78cbd99d9af506f3c96a0f61d7d0954c5 Please recompile the current git/master version to test it. Maik Created attachment 175346 [details]
Updated Stacktrace after potential fix
Hi,
thanks for the quick response. I made a clean build and the bug still occurs.
Best,
Finn
I don't think we can fix it, ultimately it crashes in libEGL_nvidia.so.0 ==> libdrm-2.4.123/xf86drm. Maik I agree with Maik. This crash is located in Nvidia libraries. You must report this dysfunction to your distro packager with all details to reproduce. Git commit 30e93f6ecf3ccd6bcf70317a0c279af0b405f161 by Maik Qualmann. Committed on 30/10/2024 at 07:37. Pushed by mqualmann into branch 'master'. first check the platform name on Wayland M +1 -1 core/libs/dimg/filters/icc/iccsettings_p_desktop.cpp M +1 -2 core/utilities/setup/setup.cpp https://invent.kde.org/graphics/digikam/-/commit/30e93f6ecf3ccd6bcf70317a0c279af0b405f161 If you enable Qt debug with: export QT_LOGGING_RULES="digikam*=true" Do you see these messages when you run the setup? ==> Desktop platform is not X11 Maik Created attachment 175357 [details]
digikam log
Hi, I added a log file. But to me it looks like the message `Desktop platform is not X11` is logged where you expect it. In the meantime, I have also checked if the error occurs in older versions (8.3 and 8.4), because I am sure that I was able to run it on my hardware in 8.3, but now the error occurs in this older version as well. I also checked if the error occurs on my laptop running the same distribution. Here the error does not occur, even though the machine is also using the wayland protocol on qt6.8.0, reinforcing the assumption that this error is related to my NVIDIA GPU being used in a wayland session. I will now try to find the root cause and keep you updated on my findings. Thanks for your help so far. Finn (In reply to caulier.gilles from comment #16) > I agree with Maik. This crash is located in Nvidia libraries. You must > report this dysfunction to your distro packager with all details to > reproduce. Ok I've opened a topic at the EndeavourOS forum. I imagine this needs to be reported to the Arch packager really but I'll try EndeavourOS first as past experience suggests it will take a regular Arch user to report it before they will look at it. Thank you both for investigating this. https://forum.endeavouros.com/t/nvidia-wayland-bug-libegl-nvidia-so-0-libdrm-2-4-123-xf86drm/62482 This bug seems to be a duplicate of 492191. The suggested fix (using the current app image) does not work for me as it does not launch. The dev branch build still does not fix the bug. Maybe other people that experience the bug can share what there experience with the app image was. Hi, just want to share my findings. Other pop-ups that lead to a crash are: - Tools->Maintenance - Help -> OnlineHandbook Other pop-ups that do not lead to a crash are: - Other settings (change language. keyboard shortcuts, toolbars, notifications, database migration) - All other menus in tools - tag manager I have not looked for similarities among these components Hi there, Sorry for the spam, but I was able to narrow it down a bit. Both `Setup::Setup(QWidget* const parent)` and `void MaintenanceDlg::readSettings()` (called by `MaintenanceDlg::MaintenanceDlg(QWidget* const parent)`) contains the following lines: ```C++ winId(); DXmlGuiWindow::setGoodDefaultWindowSize(windowHandle()); DXmlGuiWindow::restoreWindowSize(windowHandle(), group); resize(windowHandle()->size()); ``` When I comment these lines out of the code, both dialogs (maintenance and configure digikam) are displayed without errors. As I have never worked with Qt nor am I a native C++ programmer, I do not know what this means. Nor do I know how to proceed with this bug / who to contact for further investigation. Best, Finn OK, thanks, that's interesting. The code is actually valid and is used with WinId() in other KDE programs. The WinId() function forces a window handler to be created in the constructor. Depending on the driver, this may cause problems under Wayland. But we can change that. Maik That sounds good. One more input from my side is that the code is also present in `TagsManager* TagsManager::instance()` and executed without any problems. Which seems kind of weird. If I can test anything or help in any other way, please let me know. Otherwise, I've reached the end of my abilities and don't know how I can help on my own. Best, Finn Git commit 0cd12b2b9d0b8354a44467e9da13104bc4085df4 by Maik Qualmann. Committed on 02/11/2024 at 17:12. Pushed by mqualmann into branch 'master'. trying to fix crashes with dialogs under Wayland Related: bug 468980 M +40 -0 core/libs/dialogs/dconfigdlg.cpp M +10 -0 core/libs/dialogs/dconfigdlg.h M +13 -9 core/libs/dialogs/webbrowserdlg.cpp M +1 -0 core/libs/dialogs/webbrowserdlg.h M +1 -7 core/showfoto/setup/showfotosetup.cpp M +12 -0 core/utilities/maintenance/main/maintenancedlg.cpp M +4 -0 core/utilities/maintenance/main/maintenancedlg.h M +0 -5 core/utilities/maintenance/main/maintenancedlg_settings.cpp M +1 -10 core/utilities/setup/setup.cpp https://invent.kde.org/graphics/digikam/-/commit/0cd12b2b9d0b8354a44467e9da13104bc4085df4 Git commit 2ceffbea84bcb2d6efc7309285d1b3b450fa227f by Maik Qualmann. Committed on 02/11/2024 at 17:37. Pushed by mqualmann into branch 'master'. port more possible dialogs Related: bug 468980 M +13 -8 core/libs/album/widgets/albumselectdialog.cpp M +4 -0 core/libs/album/widgets/albumselectdialog.h M +2 -2 core/libs/dialogs/dconfigdlg.cpp M +13 -8 core/libs/dialogs/deletedialog.cpp M +2 -1 core/libs/dialogs/deletedialog.h M +4 -4 core/libs/dialogs/webbrowserdlg.cpp M +6 -10 core/libs/dplugins/widgets/dplugindialog.cpp M +2 -5 core/libs/dplugins/widgets/dplugindialog.h M +2 -2 core/utilities/maintenance/main/maintenancedlg.cpp https://invent.kde.org/graphics/digikam/-/commit/2ceffbea84bcb2d6efc7309285d1b3b450fa227f Git commit 39ebada65b3d1e2f9f966b216c87c8d6895c3422 by Maik Qualmann. Committed on 02/11/2024 at 18:36. Pushed by mqualmann into branch 'master'. port all possible dialogs Related: bug 468980 M +11 -5 core/dplugins/generic/tools/expoblending/blendingdlg/expoblendingdlg.cpp M +4 -0 core/dplugins/generic/tools/expoblending/blendingdlg/expoblendingdlg.h M +0 -1 core/libs/dialogs/dconfigdlg.cpp M +0 -1 core/libs/dialogs/deletedialog.cpp M +11 -27 core/libs/dplugins/widgets/dwizarddlg.cpp M +4 -0 core/libs/dplugins/widgets/dwizarddlg.h M +13 -8 core/libs/tags/manager/tagsmanager.cpp M +12 -4 core/libs/timeadjust/clockphotodialog.cpp M +4 -0 core/libs/timeadjust/clockphotodialog.h M +16 -11 core/showfoto/stackview/showfotostackviewfavoriteitemdlg.cpp M +4 -0 core/showfoto/stackview/showfotostackviewfavoriteitemdlg.h M +12 -5 core/utilities/geolocation/geoiface/bookmark/bookmarksdlg.cpp M +1 -0 core/utilities/geolocation/geoiface/bookmark/bookmarksdlg.h M +14 -7 core/utilities/import/dialogs/capturedlg.cpp M +1 -0 core/utilities/import/dialogs/capturedlg.h https://invent.kde.org/graphics/digikam/-/commit/39ebada65b3d1e2f9f966b216c87c8d6895c3422 Hi, thanks for the quick fix. I built it locally and so far I did not experience any crashes. The only notable difference is that the window size now does not seem to be optimal though this is a small nitpick. Nonetheless I will attach a Screenshot to show what I mean. Once again thank you for the quick fix. Best, Finn Created attachment 175476 [details]
Current window size
I assume it was saved that small, if you enlarge it, what will it look like the next time you open it? Maik A quick test here under a Wayland session shows no difference to X11. The calculation of a good window size only works until the user has changed the size himself, then the user size is always restored. Maik Ups thats on me. Forgot to issue `make install/fast` therefore I was using my locally patched version. Sorry for. That now I can surely confirm that it works. Sorry for that. Finn Great, thanks for your effort and feedback, I close the bug now. Maik |