Created attachment 155661 [details] Apple crash report from today Hi, yesterday as I was working on a .kra and a TIFF file simultaneously, Krita suddenly just crashed (for the first time btw!) and even though I initially could reopen Krita, when trying to open my files it crashed again. I restarted my iMac and then I couldn't even open Krita anymore. Just instantly crashes when clicking on the symbol in the Dock. I've downloaded the latest build and re-installed, but no change. Then I noticed by chance that there was a macOS update due - was still on 13.1 - and did that. After restarting again Krita finally opened up and I've continued working on the .kra while converting the TIFF to a PNG with Apple Preview, to avoid another crash. Worked fine up until now, I was just working on a .kra-file, as Krita suddenly disappeared again and now I can't open Krita at all anymore. :( STEPS TO REPRODUCE 1. Open Krita 2. 3. OBSERVED RESULT Crash EXPECTED RESULT Not crashing I guess SOFTWARE/OS VERSIONS Windows: macOS: 13.2 Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Someone in the Krita-Artists-Forum mentioned it might be connected to a faulty ICC profile and I've just switched to the standard monitor profiles in the macOS settings. Could actually open Krita and the autosave-file from the previous session, but it crashed again after a few seconds. I'm attaching the new crash report (Nr.3).
Created attachment 155662 [details] Crashing again after switching to default monitor ICC profiles.
That was me... Could you attach * the .kra file * a screenshot of the display colors and calibration screen from the settings app * the krita.log and krita-sysinfo.log files from ~/Library/Application Support
Created attachment 155670 [details] Additional files that hopefully provide information. Not sure if the display screenshot is what you've asked for.
(In reply to Halla Rempt from comment #3) > That was me... Could you attach > > * the .kra file > * a screenshot of the display colors and calibration screen from the > settings app > * the krita.log and krita-sysinfo.log files from ~/Library/Application > Support Thank you very much for taking care of this! The .kra file is too big for this system, so I'm adding a Dropbox link to it: https://www.dropbox.com/s/4lm8o79hzhfdm5f/funghipriests.kra?dl=0 In addition, I've been using GeforceNow on the side from time to time - could that be related to this problem since it's providing some sort of virtual display that doesn't match the system?
Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information.
Assigning, the first crash report looks like a completely empty ICC profile makes it past our checks.
Created attachment 155700 [details] Not sure if this adds anything, helps, but it just happened again. Couldn't get Krita to work today so far.
The example file opens fine here, it uses the standard Elle sRGB color profile. Given it still crashes for you, could you try temporarily removing the screens' calibrated color profiles, set the default "LCD color" profile on them, then try launching Krita again? If it stops crashing, please attach those two color profiles here. Otherwise, please check the preferences file -- <your home folder>/Library/Preferences/kritarc. Open it, then try the following, one Entry At A Time: - check any "monitorProfile" entries and remove them - check any "FileX" and "NameX" entries in the [RecentFiles] section and remove them, where X is a number In both cases, save (but don't close TextEdit) and try launching Krita again. Once and if it stops crashing then, send us the file corresponding to the entry that you last removed.
Created attachment 155721 [details] Couldn't remove any color profiles from the system, but managed to repair some of them via ColorSync.
Thank you very much for the suggestion. I couldn't remove any color profiles from the system, but found the "fix" button in the ColorSync tool and it did work on my recently created profiles that I'm actually using right now. Namely "CintiqPro24P_19_01_2023.icc" and "Color_LCD_19_01_2023.icc". I've also deleted the entries in the preference file as you described and Krita launches again. Hooray! I'm hesitant to say it's fixed for good, but definitely a big step forward. Thank you again!
Glad to hear that! Still, can you get a copy of those broken color profiles? So that we can help other Cintiq users not crash on the same spot in the future.
Created attachment 155735 [details] Color Profiles Apologies, had to figure out how to extract those color profiles first. Not the most techy artist here. ;) Wacom Color Manager directly installs them into my system and I've never had to get to them. But I managed to and here's the two color profiles in use. Hope it helps and I'm glad to provide you with anything further to resolve this issue. Thank you all!
Bingo, I think I've found the reason why it crashes. Incoming fix.
Git commit 9684e5f102af371dc7e1a216189225cfaf4aa2f4 by L. E. Segovia. Committed on 28/01/2023 at 20:44. Pushed by lsegovia into branch 'master'. YCbCr: ensure we have a default color profile in place Found while checking the below bug out. M +1 -1 plugins/color/lcms2engine/colorspaces/ycbcr_f32/YCbCrF32ColorSpace.h M +1 -1 plugins/color/lcms2engine/colorspaces/ycbcr_u16/YCbCrU16ColorSpace.h M +1 -1 plugins/color/lcms2engine/colorspaces/ycbcr_u8/YCbCrU8ColorSpace.h https://invent.kde.org/graphics/krita/commit/9684e5f102af371dc7e1a216189225cfaf4aa2f4
Git commit a5ad124f5d878f9bd249217432ffcaf6b93d12fb by L. E. Segovia. Committed on 28/01/2023 at 20:47. Pushed by lsegovia into branch 'master'. KisImportExportManager: ensure a color space with no profile is rejected on load It was possible (unsure how, yet) to construct a color space that had no profile in it. This would usually make it past the impex plugins (unless there was a transform), but it would make the usage logger crash because it records the profile name. M +7 -0 libs/ui/KisImportExportManager.cpp M +5 -4 plugins/impex/tiff/kis_tiff_import.cc https://invent.kde.org/graphics/krita/commit/a5ad124f5d878f9bd249217432ffcaf6b93d12fb
Git commit 52eaeee8afe99005374425ed2caadce6d7b1dc1c by L. E. Segovia. Committed on 28/01/2023 at 20:48. Pushed by lsegovia into branch 'krita/5.1'. YCbCr: ensure we have a default color profile in place Found while checking the below bug out. (cherry picked from commit 9684e5f102af371dc7e1a216189225cfaf4aa2f4) M +1 -1 plugins/color/lcms2engine/colorspaces/ycbcr_f32/YCbCrF32ColorSpace.h M +1 -1 plugins/color/lcms2engine/colorspaces/ycbcr_u16/YCbCrU16ColorSpace.h M +1 -1 plugins/color/lcms2engine/colorspaces/ycbcr_u8/YCbCrU8ColorSpace.h https://invent.kde.org/graphics/krita/commit/52eaeee8afe99005374425ed2caadce6d7b1dc1c
Git commit 2f6370472556926668a5469a22d890ada776ea7d by L. E. Segovia. Committed on 28/01/2023 at 20:48. Pushed by lsegovia into branch 'krita/5.1'. KisImportExportManager: ensure a color space with no profile is rejected on load It was possible (unsure how, yet) to construct a color space that had no profile in it. This would usually make it past the impex plugins (unless there was a transform), but it would make the usage logger crash because it records the profile name. (cherry picked from commit a5ad124f5d878f9bd249217432ffcaf6b93d12fb) M +7 -0 libs/ui/KisImportExportManager.cpp M +5 -4 plugins/impex/tiff/kis_tiff_import.cc https://invent.kde.org/graphics/krita/commit/2f6370472556926668a5469a22d890ada776ea7d