This issue started appearing after the July 27th update of the Steam version of Krita. While I was drawing as usual, I noticed that the undo shortcut would more frequently cause the mouse to get stuck in color sampling mode. Additionally, every time I open the project I am working on, this error appears within three minutes.
Clicking “Ignore” causes Krita to crash, making it impossible to continue. I would like to know what might be causing this issue. Since I am currently studying illustration, I would appreciate a solution that can resolve this problem immediately.
One of the fastest ways to get a crash or error resolved is to explain step by step how to reproduce it. If a developer can recreate it on their system, then they can quickly test fixes to ensure they got the fix right. Do you know what causes it and how to reproduce it?
1 Like
Ofcurse,but I don’t think I did anything special.
I started Krita through Steam, opened my work, and used the “basic-5 size” brush to paint a halftone shadow, and an error occurred.
I was working on this piece on the morning of the 27th before the routine update, and there were no issues at that time. I just tested it myself with a completed piece and encountered the same error while painting.
It looks like a bad state can be created in KisAsyncColorSamplerHelper because of the 100ms activationDelayTimer before setting isActive to false. I’m assuming by undoing or saving or something before that timer runs out, it allows isActive to stay true and thus throws the error next time you try to activate it.
How to fix that is over my head, but that’s what I gathered from my brief look.
Thank you very much. I plan to try and see if slowing down my execution speed might help avoid the issue.
How do you normally use the color selector that gets it stuck on? Do you have a shortcut like alt to color pick, or do you select the tool in the toolbar?
So, two problems here.
- There’s a previously reported issue where safe assert dialogs are being triggered in Steam releases, the cause of which is unclear.
- The bug described by the safe assert. The cause is, somehow the color sampler is trying to be activated while already active.
SAFE ASSERT (krita): “!m_d->isActive” in file /Users/gitlab/ws/builds/GZwHuM5x/0/graphics/krita/libs/ui/tool/KisAsyncColorSamplerHelper.cpp, line 112
I’ve encountered that safe assert before, I can reproduce it with the following steps:
- Hold Shift+click to resize brush
- While holding that, switch desktops with three-finger swipe
- Let go of Shift+click, swipe back, and hit Cmd for the color picker
I haven’t been able to reproduce those steps on 5.3.0-prealpha-a0775b3b9b, it’s possible that was fixed by some recent input fixes. But that could be different than the steps triggering it here.
I usually use the shortcut key for the color picker, which corresponds to the Command key on a MacBook. However, I also have the “Undo” command bound to a shortcut on my graphics tablet, which uses the Command+Z key combination. As a result, I often encounter the issue where, after multiple undo actions, the mouse gets stuck on the color picker command. This problem is usually resolved by pressing the Command key again.
Additionally, I am not very proficient in English. The above translation was done with the help of ChatGPT, and some of the operation commands might be translated incorrectly. Please excuse any mistakes.
I think my issue is likely similar, as the shortcut key lag often causes the mouse to get stuck on the color picker tool. However, I haven’t encountered this kind of crash issue before. Perhaps I should try changing the undo shortcut to see if it helps avoid the problem?
Alright, that didn’t work. I changed the undo shortcut to a different key combination that is unrelated to the color picker shortcut, but the crash still occurred when I quickly zoomed in on the canvas using the shortcut. Perhaps I should wait for an official fix; I am currently unable to work normally.
What happens if you bind the color picker action to something other than command? It may be trying to activate it at the same time that you zoom, for some reason.
I have already tried changing the shortcut keys related to the color picker, specifically those involving the Command key, but I still experienced crashes when I quickly pressed the zoom-in shortcut. While writing this reply, I reopened the work and tested it again. Even just rapidly pressing the zoom in and out shortcuts produces the same error.
I also tried slowing down my actions, and it seems to prevent the issue. However, if I habitually press the shortcuts rapidly or use various shortcuts quickly, the error still occurs. Perhaps the recent update has made the 100-millisecond activation delay very strict? After all, this issue has never occurred before.
The recent update changed nothing about the color picker delay, the only difference is that safe assert dialogs are incorrectly active.
I confirm that holding whichever modifier key the color picker is assigned to while using the macOS native zoom gesture triggers this safe assert on 5.2.2 and 5.2.3, but not on 5.3.0-prealpha, meaning it should be fixed in the next version.
So, does that mean this bug will be fixed in the next regular update? Thank you very much. I’ll use the old version and wait for the next update.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.