Hello, this is my first post.
Thank you all you kind people, you Krita makers, for this wonderful software! I love it.
Here’s a little crash problem. I say “little” because I’ve found a workaround.
I’m on macOS 11.6 and Krita 5.0.6.
Maybe it just occurs on my system. If someone wants to try it, here are the steps:
Select “New File” and set:
4000 px width
4000 px height
150 px/inch resolution (probably irrelevant)
RGB/Alpha model (probably irrelevant)
8-bit depth (probably irrelevant)
sRGB IEC61966-2.1 (probably irrelevant)
Select any selection tool and make any random selection
On the Layers list, click the top layer so that the Selection Mask is shown in red shades
Press Cmd+M to open the Filter gallery
Effect: Krita quits
When I repeat the above steps with a new file that is only 3700 x 3700 pixels in size, Krita will not quit.
The critical height seems to be around 3780 pixels; the width seems irrelevant.
Here’s my workaround to avoid the crash when using 4000 x 4000 px:
Do the above steps 1 thru 4, but before Cmd+M do this:
Select a brush tool and paint something, e.g. paint a red dot somewhere on the red area, so that the actual mask won’t change.
Press Cmd+M to open the Filter gallery
Effect: Krita keeps running.
So it seems that only this extra paint action puts Krita into a special mode which allows me to apply filters (blur etc.) directly on the red shades of the selection layer.
And it seems this extra paint action is only needed if the image height is greater than circa 3780 pixels. In other words: It’s probably not a hardware memory problem. The memory is available. I guess the software just misses a mode change or something.
Thank you very much for your attention!
Hi, I could reproduce the crash at least once, though unfortunately not when running in a debugger. I’m trying to figure out how to get a backtrace now… But I cannot reliably trigger the crash. Still, I have seen it happen, on Linux.
ETA: what type is your Mac?
Hello @Heiny, and welcome to the forum!
Thanks for your report.
I’ll adjust the title a bit so it’s clear this is about a difficulty related to a Mac. This way it can be better found by people possibly affected by it.
Add: …the story continues, I’m to slow!
Thank you, Halla and Michelist.
Michelist, I don’t know it it’s Mac specific. Windows testers are welcome as well.
Halla, oh, Linux too. Interesting.
iMac (Retina 5K, 27-inch, 2020)
3,8 GHz 8-Core Intel Core i7
8 GB 2667 MHz DDR4
AMD Radeon Pro 5500 XT 8 GB
Display: 27-inch (5120 × 2880)
Oops, before @halla’s edit, I thought halla has tested it on her Mac.
Now I’ll go to check this on Windows and re-edit the title.
Okay, I managed to reproduce on my 2015 macbook pro as well: I suspect there’s a timing issue involved, since on my 2022 14" it wasn’t reproducible. AND I have a backtrace of sorts now:
Process: krita 
Version: 5.0.0 (???)
Code Type: X86-64 (Native)
Parent Process: ??? 
Responsible: krita 
User ID: 501
Date/Time: 2022-06-23 14:25:12.466 +0200
OS Version: Mac OS X 10.14.6 (18G95)
Report Version: 12
Anonymous UUID: B37680F4-B171-7DB9-2DF3-1066BE1597AD
Sleep/Wake UUID: 0EFE7872-79C5-42AA-93AC-EC7D5D0AC641
Time Awake Since Boot: 28000 seconds
Time Since Wake: 640000 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000040
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler 
VM Regions Near 0x40:
__TEXT 0000000108f8c000-0000000109628000 [ 6768K] r-x/r-x SM=COW /Users/USER/Desktop/krita.app/Contents/MacOS/krita
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libkritaimage.17.dylib 0x0000000109f3925e 0x109f1f000 + 107102
1 libkritaimage.17.dylib 0x0000000109f3940e KisTile::KisTile(int, int, KisTileData*, KisMementoManager*) + 174
2 libkritaimage.17.dylib 0x0000000109f486d1 0x109f1f000 + 169681
3 libkritaimage.17.dylib 0x0000000109f543ce 0x109f1f000 + 218062
4 libkritaimage.17.dylib 0x0000000109f56294 0x109f1f000 + 225940
5 libkritaimage.17.dylib 0x0000000109f561ec 0x109f1f000 + 225772
6 libkritaimage.17.dylib 0x000000010a14951f 0x109f1f000 + 2270495
7 libkritaimage.17.dylib 0x000000010a148e21 KisPaintDevice::calculateExactBounds(bool) const + 433
8 libkritaimage.17.dylib 0x000000010a15b1ee 0x109f1f000 + 2343406
9 libkritaimage.17.dylib 0x000000010a148ab3 KisPaintDevice::exactBounds() const + 99
10 libkritaui.17.dylib 0x0000000109855324 KisStatusBar::updateSelectionToolTip() + 84
11 libkritaui.17.dylib 0x000000010984c9f8 KisSelectionManager::updateStatusBar() + 72
12 libkritaui.17.dylib 0x000000010984c8de KisSelectionManager::updateGUI() + 606
13 libkritaui.17.dylib 0x0000000109b2bbe5 KisViewManager::guiUpdateTimeout() + 37
14 org.qt-project.QtCore 0x000000010c8986da QMetaObject::activate(QObject*, int, int, void**) + 2138
15 libkritaglobal.17.dylib 0x000000010b0e0bcc KisSignalCompressor::tryEmitOnTick(bool) + 188
16 libkritaglobal.17.dylib 0x000000010b0e0c28 KisSignalCompressor::slotTimerExpired() + 56
17 org.qt-project.QtCore 0x000000010c8986da QMetaObject::activate(QObject*, int, int, void**) + 2138
18 org.qt-project.QtCore 0x000000010c89fa22 QTimer::timerEvent(QTimerEvent*) + 98
19 org.qt-project.QtCore 0x000000010c891694 QObject::event(QEvent*) + 100
20 org.qt-project.QtWidgets 0x000000010b39a7b9 QApplicationPrivate::notify_helper(QObject*, QEvent*) + 265
21 org.qt-project.QtWidgets 0x000000010b39bae0 QApplication::notify(QObject*, QEvent*) + 480
22 libkritaui.17.dylib 0x0000000109aa3cd2 KisApplication::notify(QObject*, QEvent*) + 210
23 org.qt-project.QtCore 0x000000010c869f57 QCoreApplication::notifyInternal2(QObject*, QEvent*) + 167
24 org.qt-project.QtCore 0x000000010c8bf91a QTimerInfoList::activateTimers() + 1002
25 libqcocoa.dylib 0x000000010f1d6855 0x10f1a2000 + 215125
26 com.apple.CoreFoundation 0x00007fff3549c683 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
27 com.apple.CoreFoundation 0x00007fff3549c629 __CFRunLoopDoSource0 + 108
28 com.apple.CoreFoundation 0x00007fff3547ffeb __CFRunLoopDoSources0 + 195
29 com.apple.CoreFoundation 0x00007fff3547f5b5 __CFRunLoopRun + 1189
30 com.apple.CoreFoundation 0x00007fff3547eebe CFRunLoopRunSpecific + 455
31 com.apple.HIToolbox 0x00007fff346de1ab RunCurrentEventLoopInMode + 292
32 com.apple.HIToolbox 0x00007fff346ddee5 ReceiveNextEventCommon + 603
33 com.apple.HIToolbox 0x00007fff346ddc76 _BlockUntilNextEventMatchingListInModeWithFilter + 64
34 com.apple.AppKit 0x00007fff32a7679d _DPSNextEvent + 1135
35 com.apple.AppKit 0x00007fff32a7548b -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1361
36 com.apple.AppKit 0x00007fff32a6f5a8 -[NSApplication run] + 699
37 libqcocoa.dylib 0x000000010f1d73be 0x10f1a2000 + 218046
38 org.qt-project.QtCore 0x000000010c865d37 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 471
39 org.qt-project.QtCore 0x000000010c86a5b2 QCoreApplication::exec() + 130
40 org.krita 0x0000000108f9cf92 0x108f8c000 + 69522
41 libdyld.dylib 0x00007fff613fa3d5 start + 1
So far I have not been able to provoke it on Windows 10 with Krita 5.0.6. But that doesn’t mean it can’t happen on Windows.
I can crash Krita even with 2480x3508 document on Windows 10
Maybe due to my lower spec
If the specs are involved, I probably have to use a much larger canvas…
Could you get the kritacrash.log file from %APPDATA% and attach it to my bug report?
Is the info enough if I didn’t install dbg package?
Yes, it will show enough information to compare the crashes.
Wow, you folks are very fast and agile. Thank you!
Halla, your comment re “timing” is interesting. I just did another test; this time I waited 5 seconds before I pressed Cmd+M (no prior paint actions this time), and it didn’t crash. So the help of the paint action is probably just coincidence; it just added some seconds in my workflow.
Also nice to know in this “timing” context: In my previous tests with Cmd+M the color curve would sometimes appear, and only when I clicked the Gaussian Blur section it would crash. I guess it took me about 3 seconds to go from the color curve to the Gauss function.
When I paint on the red shades before pressing Cmd+M, I get no crash. But when I paint and undo that paint and then immediately press Cmd+M, I get the crash. So whatever the problem is – timing or not – the undo action seems to reset the crash potential (or crash “timing”).
One more test variation. I just made several tests without delay and without paint action, but this time I pressed Cmd+U instead of Cmd+M. No crashes. Just Cmd+U to open the hue filter, then click “curves” or “blur” in one second. No crash.
Hi Halla, thanks again for your kind attention.
Just curious (I’m trying to learn): Your bug report says “Importance: NOR crash”.
May I ask what the letters “NOR” mean in this context?
I know the logical operator “not OR”. But that’s not meant here probably?
NOR is the priority – we don’t use it so it’s always that. Other options are like VHI.