SUMMARY Worked with no problems before, now takes a long time to respond even to opening a new file, then crashes. Once I managed to open a file it then had a very delayed response time to any brush strokes etc. even after being assigned 7GB of RAM. STEPS TO REPRODUCE 1. Open Krita 2. Click open file 3. If file manages to open before the software crashes, literally try to do anything else. OBSERVED RESULT At First, Krista will say "not responding", then crashes completely. EXPECTED RESULT Expected to work with no issues and not crash. SOFTWARE/OS VERSIONS Windows: Windows 10 - 64bit macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Hi Julia, This is obviously not normal behaviour, and specific to your system. * Did this start to happen when you updated Krita? * Or did you get an OS update? * Could you attach the output of Help->System Information for Bug Reports to this bug? * Can you try to append a crash log (see https://docs.krita.org/en/reference_manual/dr_minw_debugger.html#dr-minw) ? * Does this still happen if you start krita as administrator or another user?
Created attachment 122989 [details] Information for bug reports
I used Krita yesterday and I had no problems with it, when I noticed it crashing I updated my version of Krita this morning and the issue has not gone away. I have not gotten an OS update recently. The issue continues when I open the software as administrator
You're running out of memory: 03 Oct 2019 14:45:51 +0100: WARNING: C:/Users/julia/Pictures/tumblr/kimetsu no yaiba/nezuko/raw2.kra is running out of memory:Image size: 7.5 GiB - layers: 3.9 GiB - projections: 3.5 GiB - instant preview: 0 B Memory used: 73.9 MiB / 5.9 GiB image data: 73.8 MiB / 5.9 GiB pool: 0 B / 0 B undo data: 112.0 KiB Swap used: 0 B The strange thing is that Krita doesn't start swapping. Can you attach a screenshot of the General tab of the Performance page of Krita's settings dialog? And maybe make available a link so I can download your raw2.kra file and see what's up with it?
Created attachment 122991 [details] raw2.kra file I've been using
Created attachment 122992 [details] General tab of the performance settings
Created attachment 122993 [details] updated and resaved kra file Okay, there's no reason whatsoever for this image to take so much memory. I think that there's a layer that has pixels way outside the image boundaries. I did a trim to image size, and that brought down the image size immediately. I've attached the new version.
Seems to be working fine now, I should have checked that before, thank you so much!
Thanks for your patience, too :-)
Btw, your problem is solved... But we still have at least two issues here that we as developers need to fix: * apparently it's still possible to not use swap when we run out of memory -- and we need to know why * apparently we don't have something in place that makes completely empty tiles not take any memory.
Btw, we do need some more information for you because of the swap issue. Could you tell us, as exact as possible, what CPU your computer has?
I'm going to assume that was an AMD with the AMD random generator bug. So only the problem remains that we create gobs of tiles in memory that are completely empty in our projection composition code. Maybe we should have a garbage collector for those tiles...
Created attachment 123123 [details] Device Specification
Hello, I apologise that it took me so long to come back to this thread. One thing which I didn't mention before was that every now and then, while i was using a lenovo active pen, it would draw a continous straight line from where the pen was and to outside of the image. This was when I noticed that the size of the image was dramatically increasing, and I had to undo the last brush stroke as well as trim the image every time it happened (as you previously suggested). Do you think this could be an issue with the intraction between the device and the pen as opposed to a problem with the software?
Hi Julia, Thanks for the info! It confirms that the problem with the swap file not being used was because of the bug in the random number generator in the cpu in your laptop. And, yes, what you describe could have caused the problems with the image taking so much memory.
We now have a system in place that reclaims empty tiles, and an option to only save pixels inside the image boundaries when saving to .kra, so I'm going to mark this closed.