Created attachment 145900 [details] Crash log SUMMARY Crash occurred while using the Freehand Selection Tool. I'm not sure exactly what I did, but presumably I tried to select an area, but missed and tried to deselect it using the "Deselect" hotkey. I suppose that there was no active selection before and no selection modifiers were used. SOFTWARE/OS VERSIONS Krita Version: 5.0.2 Qt Version (compiled): 5.12.12 Version (loaded): 5.12.12 OS Information Build ABI: x86_64-little_endian-llp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: winnt Kernel Version: 10.0.17763 Pretty Productname: Windows 10 (10.0) Product Type: windows Product Version: 10
Hi, thanks for your report. This is the relevant section of the crash log: ------------------------------------------------------------------- 00007FF888AF5F90 0000000000000000 00007FF888DCB880 00000000119EBC90 libkritaimage.dll!0x1f5f90 KisSelection::pixelSelection+0x0 00007FF8869925FF 00000000119EBBD0 00000000119EBBD0 00000000223A7FA0 libkritaui.dll!0x3225ff KisSelectAllActionFactory::run(KisViewManager*)::SelectAll::paint+0x2f 00007FF888983A6C 000000004C93A8F0 00007FF888A51B45 000000005E03FE70 libkritaimage.dll!0x83a6c KisTransactionBasedCommand::redo+0x2c 00007FF888A3EB96 0000000053A9A3F0 0000000019DE6D40 000000005E03FE70 libkritaimage.dll!0x13eb96 KisStrokeStrategyUndoCommandBased::doStrokeCallback+0x76 00007FF888C49E70 0000000000000010 0000000067C93680 0000000059C271E0 libkritaimage.dll!0x349e70 KisUpdateJobItem::run+0x90 00007FF886068A90 0000000053A9A3F0 0000000059C27100 0000000000000000 Qt5Core.dll!0x28a90 QThreadPool::tryStart+0x520 00007FF886061AAF 0000000000000000 0000000000000000 0000000000000000 Qt5Core.dll!0x21aaf QThread::qt_metacall+0x69f 00007FF8B4337974 0000000000000000 0000000000000000 0000000000000000 KERNEL32.DLL!0x17974 BaseThreadInitThunk+0x14 00007FF8B6FFA2F1 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!0x5a2f1 RtlUserThreadStart+0x21 --------------------------- Basically, what seems to be going on is that KisSelection can somehow end up without a pixelSelection pointer, and crashes when it's accessed in KisSelectAllActionFactory::run at line 157. My instinct is to say we should first check if that pointer exists, but I am also wondering why that pointer is able to be missing to begin with. Maybe we should always ensure it exists by initializing, for example. I'll need to ask around.
*** Bug 449223 has been marked as a duplicate of this bug. ***
*** Bug 449249 has been marked as a duplicate of this bug. ***
*** Bug 449723 has been marked as a duplicate of this bug. ***
There are three crashes wityh 5.0.2, one is the accessibility crash that we've seem half a dozen times now: 4, 5.0.2: 00007FF8FF41D820 000000003BEED810 0000000000000000 00000000005FB749 Qt5Widgets.dll!0x2d820 QWidget::windowHandle+0x0 00007FF8FF5F6DBD 00000000279D9650 000000006A8F2E7F 00000000005FB5F0 Qt5Widgets.dll!0x206dbd QAccessibleWidget::window+0x2d 000000006A8FC427 000000000959C1E0 00000000005FB690 00000000005FBEF0 qwindows.dll!0x7c427 000000006A8F1D02 0000000000000000 00000000005FB6C8 00000000005FB740 qwindows.dll!0x71d02 00007FF90F2F5E57 0000000000000040 00007FF900000000 0000000000000070 UIAutomationCore.dll!0x45e57 1, 5.0.2: AddrPC Params 00007FF820AAE593 0000000030DC7930 00007FF820AB92C4 0000000002971E40 Qt5Widgets.dll!0x2e593 QWidget::window+0x23 00007FF820A8E653 0000000000000001 0000000002971E40 0000000024BA5BB0 Qt5Widgets.dll!0xe653 QApplicationPrivate::sendSyntheticEnterLeave+0xc3 00007FF820AC5DDA 0000000000000000 0000000000000000 0000000002971E40 Qt5Widgets.dll!0x45dda QWidgetPrivate::setVisible+0x29a 00007FF820AC516C 0000001300000034 00000000005FBC80 0000000015122430 Qt5Widgets.dll!0x4516c QWidget::qt_static_metacall+0x44c 00007FF82184A05A 0000000024C30AF0 00007FF821F50D5F 0000000000000000 Qt5Core.dll!0x22a05a QObject::event+0xda 00007FF820AC63BC 0000000024BA5BB0 0000000002971E40 0000000024C31CF0 Qt5Widgets.dll!0x463bc QWidget::event+0x3dc 00007FF820C33344 00000000005FFB80 0000000000000000 00000000005FFB80 Qt5Widgets.dll!0x1b3344 QToolButton::event+0x24 AddrPC Params 00007FF888AF5F90 0000000000000000 00007FF888DCB880 00000000119EBC90 libkritaimage.dll!0x1f5f90 KisSelection::pixelSelection+0x0 00007FF8869925FF 00000000119EBBD0 00000000119EBBD0 00000000223A7FA0 libkritaui.dll!0x3225ff KisSelectAllActionFactory::run(KisViewManager*)::SelectAll::paint+0x2f 00007FF888983A6C 000000004C93A8F0 00007FF888A51B45 000000005E03FE70 libkritaimage.dll!0x83a6c KisTransactionBasedCommand::redo+0x2c 00007FF888A3EB96 0000000053A9A3F0 0000000019DE6D40 000000005E03FE70 libkritaimage.dll!0x13eb96 KisStrokeStrategyUndoCommandBased::doStrokeCallback+0x76 00007FF888C49E70 0000000000000010 0000000067C93680 0000000059C271E0 libkritaimage.dll!0x349e70 KisUpdateJobItem::run+0x90 00007FF886068A90 0000000053A9A3F0 0000000059C27100 0000000000000000 Qt5Core.dll!0x28a90 QThreadPool::tryStart+0x520 00007FF886061AAF 0000000000000000 0000000000000000 0000000000000000 Qt5Core.dll!0x21aaf QThread::qt_metacall+0x69f 00007FF8B4337974 0000000000000000 0000000000000000 0000000000000000 KERNEL32.DLL!0x17974 BaseThreadInitThunk+0x14 00007FF8B6FFA2F1 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!0x5a2f1 RtlUserThreadStart+0x21
https://bugreports.qt.io/browse/QTBUG-83387 might be relevant.
Note: 16:05:04 < windragon> yes, there is a Qt bug report with similar things, though not exactly the same: https://bugreports.qt.io/browse/QTBUG-83387 16:05:54 < windragon> tl;dr it *might* be that some code is calling disconnect() to disconnect *all* signals from some objects and breaks the cleanup code that Qt uses internally 16:06:11 < windragon> but I have no way to verify that
Hi, Wolthera! > Basically, what seems to be going on is that KisSelection can somehow end up without a pixelSelection pointer You are right. There is a race condition between the GUI thread and the worker threads. The check for `if (!image->globalSelection())` happens in the GUI thread and skips the creation of a job that initializes selection. But by the time the select-all stroke gets into the execution queue, the previous jobs have already removed the selection, hence the crash.
*** Bug 448774 has been marked as a duplicate of this bug. ***
Git commit 45ebcf40a1f8632649cb8e427ee793241273dd16 by Dmitry Kazakov. Committed on 18/02/2022 at 08:16. Pushed by dkazakov into branch 'master'. Fix a race condition in Select All action It might happen that the selection has ben removed while the select-all action is still waiting in the strokes queue. Therefore the action should check for the presence of the global selection in the context of the worker thread, not the GUI one. M +7 -5 libs/ui/actions/kis_selection_action_factories.cpp https://invent.kde.org/graphics/krita/commit/45ebcf40a1f8632649cb8e427ee793241273dd16
Just for your information: I have fixed on the part of the bug that is related to the select-all action. The accessibility issue is still **not fixed**.
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1340
Git commit 796bfaddd99d4fa7c70a33964705cd85249e94ed by Halla Rempt. Committed on 18/02/2022 at 12:00. Pushed by dkazakov into branch 'master'. Return 0 for Window if there is no widget This should be safe: I've checked all calls to window() in the ui automation module, and they all check whether 0 is returned before dereferencing the pointer. A +32 -0 3rdparty/ext_qt/0001-Return-0-for-Window-if-there-is-no-widget.patch M +3 -0 3rdparty/ext_qt/CMakeLists.txt https://invent.kde.org/graphics/krita/commit/796bfaddd99d4fa7c70a33964705cd85249e94ed
Git commit 6cef8b54a8adfc4f7643bec6b261c5ff7b644213 by Dmitry Kazakov. Committed on 23/02/2022 at 08:48. Pushed by dkazakov into branch 'krita/5.0'. Fix a race condition in Select All action It might happen that the selection has ben removed while the select-all action is still waiting in the strokes queue. Therefore the action should check for the presence of the global selection in the context of the worker thread, not the GUI one. M +8 -5 libs/ui/actions/kis_selection_action_factories.cpp https://invent.kde.org/graphics/krita/commit/6cef8b54a8adfc4f7643bec6b261c5ff7b644213
Git commit e6b6992349eeb8166f97e0eee6c74205258de6a2 by L. E. Segovia, on behalf of Halla Rempt. Committed on 25/02/2022 at 15:47. Pushed by lsegovia into branch 'krita/5.0'. Return 0 for Window if there is no widget This should be safe: I've checked all calls to window() in the ui automation module, and they all check whether 0 is returned before dereferencing the pointer. (cherry picked from commit 796bfaddd99d4fa7c70a33964705cd85249e94ed) (cherry picked from commit 981101bde88050af5078635da9070786af108095) A +32 -0 3rdparty/ext_qt/0001-Return-0-for-Window-if-there-is-no-widget.patch M +3 -0 3rdparty/ext_qt/CMakeLists.txt https://invent.kde.org/graphics/krita/commit/e6b6992349eeb8166f97e0eee6c74205258de6a2
Please do test the latest stable nightly: https://binary-factory.kde.org/job/Krita_Stable_Windows_Build/ -- we need feedback from people with systems where the issue crops up on whether this really fixed it.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!