Created attachment 127048 [details] Fill layer config files SUMMARY I saved a file after finishing a drawing. A few days later, I tried opening the file again. Krita crashes while trying to load it. I opened the file in an archiving program and checked that it did not contain any ZIP corruption. Deleting the annotations folder did not help either. I took a look at the maindoc.xml file and started deleting layers in it to see if it helps. After some trial and error, I managed to narrow it down to a Fill layer. Deleting it, and it alone, allowed the file to read. Attached are the files corresponding to that layer. Here is the log I got from krita.log: > KRITA DID NOT CLOSE CORRECTLY > There were 1 crashes in total in the crash log. > > SESSION: 27 Mar 2020 04:42:47 +0300. Executing C:\PortableApps\krita-x64-4.2.9\bin\krita.exe > Krita Version: 4.2.9, Qt version compiled: 5.12.7, loaded: 5.12.7. Process ID: 11688 > > 27 Mar 2020 04:43:47 +0300: Importing application/x-krita to application/x-krita. Location: F:/Pictures/WIPs/Ace_and_Martin/Ace_Martin_Pun01.kra. Real location: FF:/Pictures/WIPs/Ace_and_Martin/Ace_Martin_Pun01.kra. Batchmode: 0 > 27 Mar 2020 04:43:49 +0300: ASSERT (krita): "m_buffer[currentIndex].loadAcquire() > 0" in file C:\Packaging\workspace\Krita_Release_Windows64_Build\krita\libs\image\tiles3\KisTiledExtentManager.cpp, line 87 Tested under Windows 7 Pro x64 with Krita 4.2.9 x64 stable.
Hi, Franck! Is it possible to share the entire original file with me? If it is private, you can sent it me to an email: dimula73 at gmail dot com. This bug seem to be ralated to: https://bugs.kde.org/show_bug.cgi?id=420322
Btw, the layer you removed doesn't seem to be a "Fill Layer". Perhaps it was a Paint Layer with Colorize Mask attached? At least the contents of Layer26 you attached looks as if it was filled with colorize mask and then rasterized...
Okay, the file is not needed, I can reproduce the crash in a unittest
*** Bug 420322 has been marked as a duplicate of this bug. ***
Hello. Sorry for the late response. For the sake of clarification, the layer’s entry in maindoc.xml was: <layer name="Layer 26" compositeop="overlay" intimeline="1" x="0" colorlabel="0" opacity="102" uuid="{7fb4448c-6309-49aa-b4a0-eb61348e6339}" visible="1" y="0" collapsed="0" locked="0" filename="layer18" nodetype="generatorlayer" generatorname="color" generatorversion="1" channelflags="1110"/>
Hi, Franck! This entry is for layer stored in folder "layer18" :) You should check attribute 'filename="layer18"'. Do you still have this file and can you reproduce the crash every time you try to open this file? Btw, how many cores your CPU has?
This bug seem to be related, the same assert is caught when opening the attached file: https://bugs.kde.org/show_bug.cgi?id=412488
No, that file doesn't help reproducing the issue... I have found another threading issue in the extents manager, but it is rather minor and cannot cause any crashes... I still cannot reproduce the original crash.
Hi, Franck! Did you have any transformation masks in your document that caused a crash?
Hi, Franck! Can you please test this package? Does it fix the crash for you? https://yadi.sk/d/K0CN26KoDcGa4g It fixes one transoformation masks threading issue, which might be the reason for your bug.
I’m sorry, I just checked but unfortunately it seems I do not have the version of the file that caused the bug anymore. I have the version from which I deleted the relevant layer, and that one loads without an issue. I still get crashes when loading other files, but most of the time they tend to open fine on the second or even the third try.
I don’t use any transform masks at all, but I’ll test that package and will report.
> I still get crashes when loading other files Can you reproduce these crashes with the package I linked? If yes, could you please get a DebugView log using this link: https://docs.microsoft.com/en-us/sysinternals/downloads/debugview You should start DebugView before starting Krita with the faulty file :)
Sorry it took so long, downloading that package took ages with my internet. Anyway, I tested it with as many as my files as possible. Loading was noticeably much slower, but I experienced no crash on loading any of the files. There were a couple of crashes when closing Krita, but I don’t think those were related at all.
Hi, Franck! If it is possible, could you also test your crashing files with this build (you need a .zip version): https://binary-factory.kde.org/job/Krita_Stable_Windows_Build/ I just want to know what exactly fixed the issue... This build is from the upcoming 4.3 release and it doesn't have my transformation mask fix. Don't feel in hurry about it, I can wait a bit :)
I tested several files and have found two that causes issues while opening. The first one: - 4.2.9 stable: loads fine; - 4.3.0 prealpha 1523: crash; - 4.3.0 prealpha with transform mask fix: loads fine. The second one: - 4.2.9 stable: crash; - 4.3.0 prealpha 1523: crash; - 4.3.0 prealpha with transform mask fix: loads fine. Note that neither file actually uses a transform mask, since that is a feature I’ve never used before. Both are private NSFW art though, so if you’re okay with that, I can email you one or both tomorrow.
Hi, Franck! Could you please send me the files you used for testing to dimula73 at gmail dot com? I will keep them in private.
Git commit 7b147c93b51bb4c7e2d0ed2148fd828c54226022 by Dmitry Kazakov. Committed on 27/04/2020 at 21:40. Pushed by dkazakov into branch 'master'. Fix threading issue when loading KisGeneratorLayer We shouldn't call the same function from both, GUI thread and a worker thread. It may lead to concurrent writes to the same image area, which is not something we are allowed to do Related: bug 420322 M +1 -1 libs/image/generator/kis_generator_layer.cpp https://invent.kde.org/kde/krita/commit/7b147c93b51bb4c7e2d0ed2148fd828c54226022
Git commit 6ba81a096f29cb1eaf5a100615e15f671a4326d8 by Dmitry Kazakov. Committed on 27/04/2020 at 21:44. Pushed by dkazakov into branch 'krita/4.3'. Fix threading issue when loading KisGeneratorLayer We shouldn't call the same function from both, GUI thread and a worker thread. It may lead to concurrent writes to the same image area, which is not something we are allowed to do Related: bug 420322 M +1 -1 libs/image/generator/kis_generator_layer.cpp https://invent.kde.org/kde/krita/commit/6ba81a096f29cb1eaf5a100615e15f671a4326d8