Bug 406250

Summary:	Color space conversion with clone layer crashes - only in specific circumstances
Product:	[Applications] krita	Reporter:	M <manuel.snudl.zeidler>
Component:	Color models	Assignee:	Dmitry Kazakov <dimula73>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	ghevan, griffinvalley
Priority:	NOR	Keywords:	triaged
Version:	unspecified
Target Milestone:	---
Platform:	Manjaro
OS:	Linux
Latest Commit:		Version Fixed In:
Attachments:	file:///home/snu/gdb output.txt

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:

STEPS TO REPRODUCE
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:

Krita

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

Qt

  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

run

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 ***