Created attachment 188619 [details] drkonqi.txt, gdb.txt, gdb_output.txt, krita.log, krita-sysinfo.log # SUMMARY I encountered a program crash after overwriting gradient resources. I have a suspicion that the previous fix didn't actually resolve the root cause but only masked it. The issue re-emerged when I was working on multiple files at the same time. After several attempts, I have found a consistent way to reproduce the issue: 1. Open Krita and create a new document. 2. Draw a stroke on the layer, then open the "Layer Styles" dialog. 3. Enable "Gradient Overlay", set the "Blending Mode" to "Normal" and "Opacity" to "100%". Create a new gradient preset, keep the default name (do not rename it), and click OK. 4. Re-enter the "Layer Styles" dialog and change the "Angle" of the Gradient Overlay to a random value. 5. Close the document without saving, then create another new document. 6. Open "Layer Styles" in the new document, create a different gradient effect but keep the same default name as before, then click OK. 7. The application crashes immediately. # SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.5.5 KDE Frameworks Version: 6.22.0 Qt Version: 6.10.1 Kernel Version: 6.18.5-zen1-1-zen (64-bit) Graphics Platform: Wayland Processors: 18 × Intel® Core™ Ultra 5 125H Memory: 32 GiB of RAM (30.8 GiB usable) Graphics Processor: Intel® Arc ADDITIONAL INFORMATION Previous bug: https://bugs.kde.org/show_bug.cgi?id=484796 Reproduction video: https://drive.google.com/file/d/1mZhAHcYj3OC0Xzowc9vEbBohLRWhfTBQ There's also a coredump, but I'm not sure if it's useful.
I cannot reproduce the crash/assert here. But if I create two layers with different gradients names "unnamed", then after reloading both layers will have the same gradient, even though both are loaded.
(In reply to Dmitry Kazakov from comment #1) > I cannot reproduce the crash/assert here. But if I create two layers with > different gradients names "unnamed", then after reloading both layers will > have the same gradient, even though both are loaded. I tried again, but the issue persists. I might have missed a step in my description, so could you please check the video? My apologies for forgetting to set the permissions to public earlier: https://drive.google.com/file/d/1mZhAHcYj3OC0Xzowc9vEbBohLRWhfTBQ
Hi, SharpIce! Could you please also retest with the official AppImage?
(In reply to Dmitry Kazakov from comment #3) > Hi, SharpIce! > > Could you please also retest with the official AppImage? I've tested this on both AppImage and Windows 11, and the issue persists. After checking with a few friends, it seems to work fine on X11. Below is the terminal log generated while running the AppImage: ``` Bundle "/home/sharpice/.local/share/krita/EO_Bundle.bundle" is broken. File "gradients/krita.svg" is missing QObject::startTimer: Timers cannot have negative intervals Could not find platform independent libraries <prefix> Could not find platform dependent libraries <exec_prefix> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>] /tmp/.mount_krita-gakadI/usr/lib/krita-python-libs/krita added to PYTHONPATH ASSERT (krita): "embeddedResources.last().data()" in file /builds/graphics/krita/libs/image/kis_asl_layer_style_serializer.cpp, line 756 zsh: IOT instruction (core dumped) ./krita-5.2.14-x86_64.AppImage ```
Git commit d86c29e21755d5a53753a07a27708e74cf635e59 by Dmitry Kazakov. Committed on 27/01/2026 at 13:49. Pushed by dkazakov into branch 'master'. Fix loading presets with conflicting embedded resources It might happen that two paintop presets may embed resources (e.g. patterns) with the same filename, but still different. In such case they might clash in a conflict when added to the common "memory" storage. Before the patch, the preset that would load the second would just ovewrite the previously added embedded resource, effectively breaking the other preset. This patch fixes this issue by renaming embedded resources on loading, if they are going to cause a naming conflict. The resource will (hopefully) still be addressed by the preset by its md5 sum. The patch also had to fix KisPaintOpPreset::sideLoadedResources() to use exactMatch() instead of bestMatch(). exactMatch() skips fetching a resource by name/filename if md5sum is provided. M +2 -2 libs/image/brushengine/kis_paintop_preset.cpp M +90 -2 libs/image/tests/KisPaintOpPresetTest.cpp M +1 -0 libs/image/tests/KisPaintOpPresetTest.h A +- -- libs/image/tests/data/conflicting-patterns/preset-stripes-cross.kpp A +- -- libs/image/tests/data/conflicting-patterns/preset-stripes-vert-v2.kpp A +- -- libs/image/tests/data/conflicting-patterns/preset-stripes-vert.kpp M +31 -3 libs/resources/KisResourceLocator.cpp M +16 -0 libs/resources/KisResourceLocator.h M +23 -1 libs/resources/KisResourcesInterface.cpp M +34 -3 libs/resources/KisResourcesInterface.h M +20 -0 libs/resources/KoResourceLoadResult.cpp M +3 -0 libs/resources/KoResourceLoadResult.h https://invent.kde.org/graphics/krita/-/commit/d86c29e21755d5a53753a07a27708e74cf635e59
Git commit 97fbf20fafbbe37dd20d1d779bf97b61037f1a9f by Dmitry Kazakov. Committed on 27/01/2026 at 13:49. Pushed by dkazakov into branch 'master'. Fix gradient handling in the layer style dialog The patch streamlines handling of the embedded resources in the layers style. Basiclly, the of the layer style usage are currently the follwoing: 1) When loading a layer style into the global storage, the embedded resources, like gradients and patterns are loaded as sideLoadedResources(). Which moves the handling of the dependencies into KisResourceLocator, which, in turn, deduplicates resource filenames, which fixes bug 514744. 2) When a layer style is loaded into a layer style dialog, its embedded resources are moved from an internal KisLocalStrokeResources into a temporary memory- based resource storage, which is handled by KisTemporaryResourceStorageLockAdapter. 3) KisCmbGradient has been changed to use KisGenericGradientEditor instead of a normal gradient selector, which allows the user to edit gradients without saving them into the global database, which used to pollute the database (and cause bugs like 505986 and 467729) Related: bug 505986, bug 510082, bug 476729 M +17 -5 libs/image/KisAslStorage.cpp M +63 -46 libs/image/kis_asl_layer_style_serializer.cpp M +4 -2 libs/image/kis_asl_layer_style_serializer.h M +45 -7 libs/image/kis_psd_layer_style.cpp M +11 -1 libs/image/kis_psd_layer_style.h M +1 -0 libs/resources/CMakeLists.txt M +6 -0 libs/resources/KisLocalStrokeResources.cpp M +12 -0 libs/resources/KisLocalStrokeResources.h M +3 -0 libs/resources/KisMemoryStorage.cpp M +15 -0 libs/resources/KisResourceLocator.cpp M +15 -0 libs/resources/KisResourceLocator.h M +32 -0 libs/resources/KisResourceModel.cpp M +14 -0 libs/resources/KisResourceModel.h M +81 -38 libs/resources/KisResourceStorage.cpp M +1 -0 libs/resources/KisResourceStorage.h M +9 -0 libs/resources/KisTagFilterResourceProxyModel.cpp M +1 -0 libs/resources/KisTagFilterResourceProxyModel.h M +9 -0 libs/resources/KisTagResourceModel.cpp M +1 -0 libs/resources/KisTagResourceModel.h A +42 -0 libs/resources/KisTemporaryResourceStorageLock.cpp [License: GPL(v2.0+)] A +44 -0 libs/resources/KisTemporaryResourceStorageLock.h [License: GPL(v2.0+)] M +159 -90 libs/ui/dialogs/kis_dlg_layer_style.cpp M +13 -10 libs/ui/dialogs/kis_dlg_layer_style.h M +0 -1 libs/ui/kis_layer_manager.cc M +36 -21 libs/ui/widgets/kis_cmb_gradient.cpp M +8 -4 libs/ui/widgets/kis_cmb_gradient.h https://invent.kde.org/graphics/krita/-/commit/97fbf20fafbbe37dd20d1d779bf97b61037f1a9f