Bug 406250 - Color space conversion with clone layer crashes - only in specific circumstances
Summary: Color space conversion with clone layer crashes - only in specific circumstances
Status: RESOLVED DUPLICATE of bug 410776
Alias: None
Product: krita
Classification: Applications
Component: Color models (show other bugs)
Version: unspecified
Platform: Manjaro Linux
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
Keywords: triaged
Depends on:
Reported: 2019-04-05 11:34 UTC by M
Modified: 2019-09-11 09:37 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:

file:///home/snu/gdb output.txt (69.49 KB, text/plain)
2019-04-09 19:38 UTC, M

Note You need to log in before you can comment on or make changes to this bug.
Description M 2019-04-05 11:34:28 UTC
This was observed in both version 4.1.8 and the Next nightly (git f3858d1). I'm having a hard time trying to extract a pattern here. This is the most reliable method I found:

1. Start a fresh Krita instance
2. Create a new document - I used 1024*1024 px, L*a*b* 16-bit int
3. Make a clone layer, don't draw anything before or after
4. Convert image to color space: RGB 8-bit int, leave the default profile

Krita will crash immediately most of the times with the terminal message:
ASSERT (krita): "m_buffer[currentIndex].loadAcquire() > 0" in file /home/appimage/workspace/Krita_Nightly_Appimage_Build/krita/libs/image/tiles3/KisTiledExtentManager.cpp, line 87
Aborted (core dumped)

Even in this case, it doesn't fail 100% reliably. Somehow, drawing on the layer before the conversion, trying other color space and precision combinations, or having another document open at the same time will significantly reduce the chance of a crash - It is still possible to provoke it after several retries.
Comment 1 M 2019-04-05 11:38:56 UTC
And this the last terminal output for 4.1.8:
ASSERT (krita): "0 && "sanity check failed: the tile has already been removed!"" in file /build/krita/src/krita-4.1.8/libs/image/tiles3/KisTiledExtentManager.cpp, line 53
Aborted (core dumped)
Comment 2 vanyossi 2019-04-08 03:57:38 UTC
Im sorry I cannot reproduce it on c5838c03b5. I tried 5 times and it never crashed.
Comment 3 M 2019-04-08 07:01:42 UTC
If you can try the same steps in the pre-alpha with a filter layer instead of a clone layer (for example color adjustment curves). That seems to hang and crash for me almost always, too. In 4.1.8 I wasn't able to provoke a crash this way.

Other than that, what information would you need from me?
Comment 4 wolthera 2019-04-08 13:54:17 UTC
I cannot reproduce this either on the following specs:


 Version: 4.2.0-pre-alpha (git c5838c0)
 Languages: en_US, en_GB, nl
 Hidpi: false


  Version (compiled): 5.12.0
  Version (loaded): 5.12.0

OS Information

  Build ABI: x86_64-little_endian-lp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: linux
  Kernel Version: 4.15.0-46-generic
  Pretty Productname: KDE neon User Edition 5.15
  Product Type: neon
  Product Version: 18.04

Still, that assert is interesting...

Can you try to install the debug symbols and run Krita in gdb? This is not possible with the appimages as far as I know, so you need to either have a build from source or check if your repository's Krita is build with debug. Then in a terminal run:

gdb krita

then gdb starts up and tells you if it found the debug info. so then type


and finally, when krita crashes, it will in gdb freeze up instead. If that happens, go to the terminal and type

thread apply all backtrace

keep pressing enter till gdb is out of output. Then copy paste that whole thing into a bugreport or attach it as a txt. It'd be super useful to have that.
Comment 5 M 2019-04-09 19:38:14 UTC
Created attachment 119321 [details]
file:///home/snu/gdb output.txt

Here you go, this is everything from the beginning. The backtrace starts at line 703.
Comment 6 wolthera 2019-04-09 20:24:35 UTC
Thanks, I'm setting this assigned to dmitry to see if he can figure out what is going on there from the backtrace.
Comment 7 Dmitry Kazakov 2019-05-24 10:33:21 UTC
Okay, I've managed to reproduce the bug. Here it happens on Linux only
Comment 8 Dmitry Kazakov 2019-09-11 09:37:21 UTC
Bug 410776 has a way to reproduce this bug consistently

*** This bug has been marked as a duplicate of bug 410776 ***