Bug 396509

I'm sorry, but I don't see this behaviour on my windows system, so we'll have to dig in a bit.

Do you have a drawing tablet attached? If so, which brand and model? Could you also attach the output of help/system information for bug reports to this bug?
Could you please also try to follow https://docs.krita.org/en/reference_manual/dr_minw_debugger.html#dr-minw and append a crash log to the bug, so we can try to figure out what is going on?

(In reply to Boudewijn Rempt from comment #1)

Hey there! I do not have a tablet attached.

I have also tried to dig in the crash logs, but there are never any. I've actually found that link that you posted before and tried following it, but there isn't anything there. The latest item in my crashdumps folder is from April, and none of them are from Krita, and there isn't anything in the Local folder from Krita either. 

"Could you also attach the output of help/system information for bug reports to this bug?"

I am not sure what this means ^^^

Go to help->System Information for Bug Reports in Krita's menus. Click the item, copy and paste the contents.

(In reply to Boudewijn Rempt from comment #3)
> Go to help->System Information for Bug Reports in Krita's menus. Click the
> item, copy and paste the contents.

Okay I gotcha! Here is what it says:

Krita
  Version: 4.1.0

OS Information
  Build ABI: x86_64-little_endian-llp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: winnt
  Kernel Version: 10.0.17134
  Pretty Productname: Windows 10 (10.0)
  Product Type: windows
  Product Version: 10

OpenGL Info
  **OpenGL not initialized**

Hm. Try to remove Krita's settings and try again: if you're running WIndows 10, you should be able to use opengl. See https://docs.krita.org/en/KritaFAQ.html#resetting-krita-configuration

(In reply to Boudewijn Rempt from comment #5)
> Hm. Try to remove Krita's settings and try again: if you're running WIndows
> 10, you should be able to use opengl. See
> https://docs.krita.org/en/KritaFAQ.html#resetting-krita-configuration

The location instructions in the link you sent are apparently incorrect. I did a PC-wide search and it is located here:

AppData\Local\Packages\49800KritaProject.Krita_n3kgb906j1zjg\LocalCache\Local

I was also able to find the kritacrash file in that location if you still want that.

Hm, I cannot edit a comment, so I will double post here. The crash dump only has two crashes in it, and isn't including anything from between sometime in June til now, so I don't know where else to find that crash info.

Ah, yes, the krita appx places everything in a different location. We have updated the documentation. What is the channel depth and color model of your image?

I'm not sure what you mean. The only thing I ever change is the canvas size so whatever the default settings are, that's what I've got.

I mean when creating an image you can choose 8, 16 or 32 bits for channel size. Some people select 32 bits, and then their images are four times as big as normal.

Whatever it defaults to then, because I never change that. And this happens with every image that I'm working on, not just some.

Hey @cgartee0521, does the problem ever manifest in the way described here:

https://ask.krita.org/?dwqa-question=krita-4-2-0-layer-interaction-causes-crashing

Where you try to save and it just says it's waiting for the operation to finish?

I've had these issues crop up on two surface pro 4's one with older graphics drivers and one with the latest.

Created attachment 116934 [details]
Aptitude update logs

I have the same issue. I'm on Debian Stable, using a Wacom tablet, and have been using Krita for a long while with this setup without any problems. The nightly build appimage 1519ff6 from Nov 17 was fine. Now with a nightly build 6dc2f8a from Dec 11, I get the layers issue. It doesn't happen all the time, but yeah, often when I add or try to move a layer, I will notice that the response becomes sluggish, and trying to save the image leads to the "Waiting for an image operation to finish" popup. None of the options presented lets me actually save my image, with or without the image operation Krita is supposedly waiting for, or get Krita out of that state. All I can do is kill Krita from my OS. Though I don't think it's actually maxing my CPU? I'd have to take a closer look.

Another thing I've had happen with the Dec 11 build and not the Nov 17 is segfaults when confirming a transformation. Again, doesn't happen all the time, I can go transforming dozens of times, but it's often enough that it's disruptive.

As I understand, with the nightly app images for Linux I cant't get any debug stuff/core dumps? I'd have to compile myself to help debugging the dev version? Anyway, I'm trying the build from yesterday now and see how it goes.

FWIW, I've went through the commit messages on master to see if there's anything that looks like it could be the culprit for this behaviour, and all I found was the ocio update. On my end, I did one Debian update between then and now, attaching the log, just in case; so seeing that I'm not the only one with this problems I'm not sure it's relevant.

Hi Rebecca,

No, with the nightly builds you cannot get any debug dumps. But this bug was reported for 4.1.0 on Windows, so what happens with nightly builds on Linux isn't really relevant. We also know that there's a problem with some core data structures currently in git master. The author of that part is currently too busy to work on it. It's quite involved and the main reason we're postponing the release of Krita 4.2. I can't find the relevant bug reports right now, though.

I have reported an issue that may be the same or related: https://bugs.kde.org/show_bug.cgi?id=401757


I did git bisect on that one. First bad commit:

commit 5f91230f074be53379ba1461c6a1560d1f8aa1eb
Author: Boudewijn Rempt <boud@valdyas.org>
Date:   Wed Nov 28 12:44:43 2018 +0100

    add a createActions method to KoToolFactoryBase

that cannot be the same thing either, since this bug was reported before I made that commit. I am afraid we just cannot do much here without physical access to the original reporter's computer to see what might be up. That's not feasible, I'm afraid.