| Summary: | Krita crashes when am action that pushes the process memory over a certain limit | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Dennis Brown <vilesyn> |
| Component: | General | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | dimula73, halla |
| Priority: | NOR | ||
| Version First Reported In: | 2.9.7 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Dennis Brown
2015-09-16 03:50:19 UTC
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. |
