Bug 368648

Summary: File can't be opened
Product: [Applications] krita Reporter: Dave <ninjin423>
Component: GeneralAssignee: Krita Bugs <krita-bugs-null>
Status: RESOLVED FIXED    
Severity: crash CC: halla
Priority: NOR    
Version First Reported In: 3.0   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
URL: https://drive.google.com/open?id=0B_kJOb3u2J0gWk1SdG1MT0tNZGs
Latest Commit: http://commits.kde.org/krita/7ecf55492ab7bcade3ffd770858c44d26bf1e0e1 Version Fixed/Implemented In:
Sentry Crash Report:

Description Dave 2016-09-11 19:53:54 UTC 
I played around with color palettes in version 3.0. From the vector layer fill option I couldn't add my own custom palette, so I decided to open the color palette folder with the pre-integrated palettes in the windows explorer window, I copied one of them in the windows explorer window, renamed it and hoped to add colors on this copied palette (that also still had the same name back in Krita). From there I had a lot of problems, I added colors, but when using them in conjunction with vector curves and filling curves, the color was not the same. Also opened Krita in another instance, because it needed admin power to save palettes in the vector color fill box. The only other thing before the crash I did, was adding a filter layer to change my white color to transparent. At some point it always crashed (~ 2 minutes) and gives me a runtime error. I changed my krita folders under APPDATA local and roaming to bak_krita. Opened Krita again, krita folder was generated again and I can load any .kra files, but the file I was working on can't be opened now (stuck at 0%). Same results on newest release 3.0.1. <3

Reproducible: Always
Comment 1 Halla Rempt 2016-09-12 08:46:06 UTC 
Hm, the image unzips, so the zipfile isn't corrupt. It doesn't open for in krita for me either, on Linux, so this needs investigating.
Comment 2 Halla Rempt 2016-09-12 09:31:58 UTC 
Hm again... 3.0.1 can open the file without a problem, but the master branch locks up.
Comment 3 Halla Rempt 2016-09-12 10:19:35 UTC 
Git commit 86acf52509a5c2923a9dbe9d523df97581a9f124 by Boudewijn Rempt.
Committed on 12/09/2016 at 10:19.
Pushed by rempt into branch 'master'.

The image contains a filter layer that needs create a lab colorspace
for filtering. That locks the KoColorSpaceRegistry, but... We also
need access to load the profiles. And in any case, the image should
not be recomputed while loading.

So, lock the image update while loading. This has the side effect
of noticably speeding up the loading of this image for me. Which
lock to use, Lock, barrierlock, lock or blockupdates... That's a
mystery, because no apidox. I used blockUpdates because that sounds
most like what I need.

M  +2    -2    libs/ui/KisDocument.cpp

http://commits.kde.org/krita/86acf52509a5c2923a9dbe9d523df97581a9f124
Comment 4 Halla Rempt 2016-09-12 10:50:40 UTC 
Git commit 7ecf55492ab7bcade3ffd770858c44d26bf1e0e1 by Boudewijn Rempt.
Committed on 12/09/2016 at 10:16.
Pushed by rempt into branch 'rempt/T3684-custom-resource-location'.

The image contains a filter layer that needs create a lab colorspace
for filtering. That locks the KoColorSpaceRegistry, but... We also
need access to load the profiles. And in any case, the image should
not be recomputed while loading.

So, lock the image update while loading. This has the side effect
of noticably speeding up the loading of this image for me. Which
lock to use, Lock, barrierlock, lock or blockupdates... That's a
mystery, because no apidox. I used blockUpdates because that sounds
most like what I need.

M  +2    -2    libs/ui/KisDocument.cpp

http://commits.kde.org/krita/7ecf55492ab7bcade3ffd770858c44d26bf1e0e1