OS: Windows 10 Professional x64 Krita 2.9.7.6 #6577da7 Krita has crashed when using selectors, using brushes, making adjustments, and anything else that adds to the Krita process memory. For me, the memory limit has fluctuated, but the error has stayed the same. Using my usual 6900x6900x8 image size, I'm guessing this is the one many have been complaining about, but linking it to a single process. I also tested with the x86 version, using the same image, and it crashed as soon as I tried to select a single small area of the image. As the image went from lineart to, adding color, and taking up 1.2GB of memory on load, it has been crashing after every 2 actions. Every time it does crash, the process stays alive with a single thread, holding 1.4-1.7GB of memory. Just to clarify, I have 10GB of RAM free in the system when this happens. VRAM used is 1GB out of 4GB. The crash always ends up with VS Debug output as such: Exception thrown at 0x00007FF886F5A1C8 (KernelBase.dll) in krita.exe: 0x000006BA: The RPC server is unavailable. The thread 0x54d4 has exited with code 0 (0x0). The thread 0x15a8 has exited with code 0 (0x0). The thread 0x5614 has exited with code 0 (0x0). The thread 0x4220 has exited with code 0 (0x0). The thread 0x56e0 has exited with code 0 (0x0). The thread 0x5164 has exited with code 0 (0x0). The thread 0x50a4 has exited with code 0 (0x0). The thread 0x46b4 has exited with code 0 (0x0). Exception thrown at 0x00007FF87E22C5FD (msvcr110.dll) in krita.exe: 0xC0000005: Access violation writing location 0x0000000000000000. Unhandled exception at 0x00007FF87E22C5FD (msvcr110.dll) in krita.exe: 0xC0000005: Access violation writing location 0x0000000000000000. Exception thrown at 0x00007FF87E22C5FD (msvcr110.dll) in krita.exe: 0xC0000005: Access violation writing location 0x0000000000000000. Unhandled exception at 0x00007FF87E22C5FD (msvcr110.dll) in krita.exe: 0xC0000005: Access violation writing location 0x0000000000000000. Exception thrown at 0x00007FF87E22C5FD (msvcr110.dll) in krita.exe: 0xC0000005: Access violation writing location 0x0000000000000000. Unhandled exception at 0x00007FF87E22C5FD (msvcr110.dll) in krita.exe: 0xC0000005: Access violation writing location 0x0000000000000000. Exception thrown at 0x00007FF87E22C5FD (msvcr110.dll) in krita.exe: 0xC0000005: Access violation writing location 0x0000000000000000. Unhandled exception at 0x00007FF87E22C5FD (msvcr110.dll) in krita.exe: 0xC0000005: Access violation writing location 0x0000000000000000. The error never changes, and is always the same locations. Make note that the KernelBase.dll error happens most of the time, and isn't linked to the crash that I can see. It is the msvcr110.dll error that always seems to happen. Reproducible: Always Steps to Reproduce: 1. Create a large image (7000x7000x8), and start illustrating on that image 2. By the time you start to finish your lineart (if you use a draft and ink layer), you should start experiencing crashes 3. Observe the Task Manager, and go to the Details tab. Look for the Krita process with one thread, and look at the memory use 4. End the old Krita process, start another 5. Back in the Task Manager > Details, right-click the new Krita process, and choose Debug (if you have VS, or some other debugger installed) 6. Back in Krita, restore your autosave, and continue on the image you were working on, until it crashes again. 7. Once it crashes again, once again observe the memory use, and the error in the debugger. Actual Results: Exception thrown at 0x00007FF886F5A1C8 (KernelBase.dll) in krita.exe: 0x000006BA: The RPC server is unavailable. The thread 0x54d4 has exited with code 0 (0x0). The thread 0x15a8 has exited with code 0 (0x0). The thread 0x5614 has exited with code 0 (0x0). The thread 0x4220 has exited with code 0 (0x0). The thread 0x56e0 has exited with code 0 (0x0). The thread 0x5164 has exited with code 0 (0x0). The thread 0x50a4 has exited with code 0 (0x0). The thread 0x46b4 has exited with code 0 (0x0). Exception thrown at 0x00007FF87E22C5FD (msvcr110.dll) in krita.exe: 0xC0000005: Access violation writing location 0x0000000000000000. Unhandled exception at 0x00007FF87E22C5FD (msvcr110.dll) in krita.exe: 0xC0000005: Access violation writing location 0x0000000000000000. Exception thrown at 0x00007FF87E22C5FD (msvcr110.dll) in krita.exe: 0xC0000005: Access violation writing location 0x0000000000000000. Unhandled exception at 0x00007FF87E22C5FD (msvcr110.dll) in krita.exe: 0xC0000005: Access violation writing location 0x0000000000000000. Exception thrown at 0x00007FF87E22C5FD (msvcr110.dll) in krita.exe: 0xC0000005: Access violation writing location 0x0000000000000000. Unhandled exception at 0x00007FF87E22C5FD (msvcr110.dll) in krita.exe: 0xC0000005: Access violation writing location 0x0000000000000000. Exception thrown at 0x00007FF87E22C5FD (msvcr110.dll) in krita.exe: 0xC0000005: Access violation writing location 0x0000000000000000. Unhandled exception at 0x00007FF87E22C5FD (msvcr110.dll) in krita.exe: 0xC0000005: Access violation writing location 0x0000000000000000. Expected Results: I would at least expect the process to go on until memory is actually exhausted. I apologize if I am not debugging this correctly, and if this is true, I will do whatever it takes to fix that. I will be more than happy to help with this issue until it is fixed. Until then, this has been the only way I've been able to get any sort of verbose output from Krita.
Tested without OpenGL, and while it was slow, it still crashed. I have prepared a test file, and keep in mind it is very large. It is just big enough to allow Krita to use enough memory to point out the crash. Loading the file should cause Krita to use 1.2GB of memory. I was not sure if it was ok to attach here, so I have put in my Google Drive: https://goo.gl/Y9HrPZ There are many ways to cause it to crash, and that is simply to use a tool that adds to the memory use. You can use the contiguous selection tool, but it may take a few selections, and using the "add" option. The best way I've found to demonstrate, is to use the flood fill. Select the flood fill tool, and fill one of the two white space areas. Krita should crash before it is done filling the area. For me, it crashes with 1.6GB of memory in the stale process.
well, at one point you are always going to run out of memory, especially with a 32 bits build, where with a 9000x9000 image it's really easy to reach the point where allocating memory becomes impossible. A 32 bits Windows process can only allocate 2GB of memory! With a 32 bits build it really is easy to crash Krita with images that size -- that really is a matter of don't do that. If Krita shows a warning icon in the taskbar, it's time to save. If Krita shows the "We ran out of memory" message box it's too late... You can tweak the setting for the size of the swap file and the memory limits in the settings dialog. I haven't got access to a 32 bits build for Linux, and on my test system, but I can get neither 64 bits Linux nor 64 bits Windows builds to actually crash, not even if I dial down the memory limit to 1gb, as long as I keep the swap file big enough. I've tried with your test file, created 8 more layers, filled them with gradients, did contiguous selects, and krita became slow and started warning about swapping, but no crash yet.
I'm sorry that I even mentioned testing the 32bit build, because I'm talking about the 64bit build in Windows 10. I mentioned testing the 32bit build, and it crashing before that, but the 64bit build crashes around the 1.5-1.7 mark.
No problem -- but could you add a screenshot of the performance settings page of the configure dialog? And how much memory do you have? I've got 8gb in the win 10 test laptop.
Absolutely. 16GB total, 10GB free. Using OpenGL, but even VRAM is 1GB used out of 4GB. Here are the performance settings: http://i.imgur.com/J3tt4oY.jpg
Sorry, 10 free with a Krita crashed process. 12.5 free otherwise. Also, I'm not sure if this matters, but here is what the process looks like after crashing: http://i.imgur.com/RJA4Xkl.jpg Another Krita process will actually take memory from it (just noticed that today). Sorry for the imgur links. I wasn't sure if attaching screenshots was something allowed.
Yes, attaching screenshots is preferred :-). The settings do look okay, and it's extremely weird that Krita would crash with so much memory allocated. You shouldn't be hitting the swap file at all with these settings and an image of that size. And in fact, I'm not seeing that behaviour -- I really would like to find out what is going on there. Could you experiment a bit with the internal pool and undo size limit and see if that makes a difference?
I changed the internal pool to 2000Mib, and it still crashed on a single flood fill on the test file, so I changed it back to 875. I then changed the undo size to 2000mib. The Flood fill finished, and could continue to work until I went over 3GB, where It crashed again. The process had a total of 3.3GB used. Second try was 2.9GB. As I would increase the Undo by 1GB, Krita would handle 1GB more until it would crash, but it is always is 1GB above the total Undo size set. 1000MiB = 2GB limit 1999MiB = 3GB limit 2999MiB = 4GB limit (1999, and 2999 were defaulted by Krita after typing in 2000/3000 and restarting). Debugging from VS still shows the exact same errors/addresses. If you would like me to check anything else, I'll be more than happy to do so. Thank you for looking into this!
Hm, that sounds like it's the undo swap that could be broken specifically on Windows. I'm taking a look.
Hi, I did a small investigation. There are two sources of memory crashes in 32-bit mode. I did all the tests with the attached 9k x 9k image (about 600MiB each layer). 1) Wrong autosave thumbnail generation (will be fixed soon) 2) OpenGL driver needs ram for buffers to transfer textures . In the attached test case it resulted in about 400-500MiB of buffers allocated all the time in the background. 3) When Krita needs to redraw an entire canvas (canvas switch or color profile change) Krita fetches the image data in small chunks in pipeline mode. If the openGL driver is not enough to redraw these chunks too fast (and he surely isn't), it means that Krita needs a temporary storage for all this data until openGL consumes it, which in this very case is about 600MiB. Point 1) is surely a bug and will be fixed. The other two... I'm not sure. But at least it explains why Krita crashes when trying to open an attached test file in 32-bit mode.
Git commit 89c642efba098bbed418d42929872557d7bf2c6f by Dmitry Kazakov. Committed on 12/11/2015 at 15:37. Pushed by dkazakov into branch 'krita-animation-pentikainen'. Don't generate a full-scale linear QImage when generating preview for .kra M +5 -6 krita/ui/KisDocument.cpp http://commits.kde.org/calligra/89c642efba098bbed418d42929872557d7bf2c6f
Git commit dd81431d74ec167e824c726987bae860daa497aa by Dmitry Kazakov. Committed on 12/11/2015 at 19:58. Pushed by dkazakov into branch 'master'. Don't generate a full-scale linear QImage when generating preview for .kra M +5 -6 krita/ui/KisDocument.cpp http://commits.kde.org/krita/dd81431d74ec167e824c726987bae860daa497aa
Git commit e5b05eff271e30b3616ca5cacda8a53559d84ddf by Boudewijn Rempt. Committed on 13/11/2015 at 06:30. Pushed by rempt into branch 'master'. Use our own scaling method to create the preview Instead of using a QImage, either full-sized or already down-sampled, that then gets scaled again. M +2 -2 krita/image/kis_image.cc M +5 -2 krita/image/kis_image.h M +1 -1 krita/plugins/formats/ora/ora_converter.cc M +1 -1 krita/sketch/models/LayerThumbProvider.cpp M +7 -14 krita/ui/KisDocument.cpp M +5 -0 libs/widgetutils/KoUpdater.cpp M +8 -0 libs/widgetutils/KoUpdater.h M +4 -1 libs/widgetutils/KoUpdaterPrivate_p.h http://commits.kde.org/krita/e5b05eff271e30b3616ca5cacda8a53559d84ddf
The issue should be mitigated now.