Reproducing bugs in Krita - easy introduction to bug triaging and testing - beginners welcome!

It’s not really a tutorial, but there is several bugs reported that I personally cannot reproduce. Sometimes I can see that it’s for example Windows-only issue and I’m checking on Linux, sometimes it’s a bit weirder. I thought it might be better if someone with very different hardware checks them, too. So, here’s a short list of those bugs with a short instruction how to help.

I’ll see what is the response and if it’s useful to do something like that in the future, too. This post is a kind of an experiment :slight_smile:

Instruction

  1. Take a bug report that sounds interesting or doesn’t have too many answers.
    • Two responses are enough if they are “Yes” answers, and four is enough in case of any answers. And even a single one answer is valuable!
    • If all bugs have lots of answers and you’re still eager to try more - comment below! There are more :smiley: I just didn’t want to put a lot in this list.
  2. Go to the website linked. Read through the comments. Make sure you understand what is the correct result and what is the buggy result that the user complains about.
  3. Make sure your Krita version is 4.3.0 or above (you can download Krita Plus portable from the website).
  4. Try to replicate the buggy result in your Krita. There is often “steps to reproduce” list included, follow that list. Be patient, careful and test multiple scenerios, not just one - the reporter might’ve omitted something important when writing the report.
  5. Select your result underneath the correct bug here on the list.

Tips

  1. If there is anything you don’t understand (in the bug report, or the process of testing), please just comment here, I’ll be happy to help!
  2. You can use multiple versions of Krita on all systems (except for Android :slight_smile: ).
    1. On Windows, download “portable version”.
    2. On Linux, download the appimage:
    3. MacOS: 4.3.0: https://download.kde.org/stable/krita/4.3.0/krita-4.3.0.dmg

Bugs

Brush presets docker being too large affects performance of brush rendering and UI

https://bugs.kde.org/show_bug.cgi?id=423768

  • Yes, I can reproduce (brush presets affects performance)
  • No, I cannot reproduce the issue
  • I haven’t checked

0 voters

Weighted brush smoothing doesn’t work well

https://bugs.kde.org/show_bug.cgi?id=414543

  • Yes, I can reproduce (weighted brush smoothing)
  • No, I cannot reproduce the issue
  • I haven’t checked

0 voters

Moving selection is slower than moving the entire layer

https://bugs.kde.org/show_bug.cgi?id=423943
Tip: check with a huge file, to make sure you notice the difference in performance

  • Yes, I can reproduce (moving selection vs. layer)
  • No, I cannot reproduce the issue
  • I haven’t checked

0 voters

Crash after moving layer’s content and selecting transform tool

https://bugs.kde.org/show_bug.cgi?id=424757

  • Yes, I can reproduce (moving layers content and selecting transform tool)
  • No, I cannot reproduce the issue
  • I haven’t checked

0 voters

Docker becomes smaller vertically for every Tab press

https://bugs.kde.org/show_bug.cgi?id=424536
This bug might be dependent on your system, so please write a comment below with your system info, like if it’s Windows or Linux or Mac, if Linux, then what distro and DE.

  • Yes, I can reproduce (docker becomes smaller)
  • No, I cannot reproduce the issue
  • I haven’t checked

0 voters

Thanks everyone!

3 Likes

erm… I can reproduce the last one with KDE plasma, that was my literal first comment???

But yes, it’d be super cool if people could check, because that’d help us out a ton.

1 Like

The last one works at least for some dockers like the palette or advanced color selector, testing with a 4.3.1 AppImage.

I can reproduce a crash with the transform tool, but only if I duplicate the layer and create a selection before transforming.
Once it crashed with the popup message:


I have an incomplete backtrace from that AppImage without debug symbols, if that helps and fits that bug. Master doesn’t even let me open files without crashing most of the time, so it’s hard to verify :frowning_face:

What is the exact steps to reproduce:

  • duplicate the layer
  • create a selection
  • press T, move somewhere
  • press ctrl+T, transform?
    I tried making a selection just before ctrl+T, too, but I still don’t get it :frowning:
    The backtrace in the report suggests there is some undo involved. Do you undo as well?
    (There is a backtrace in the report but… I think it would be good to replicate it on Linux to get backtrace from all threads to know what was Krita doing at that point).

Crash after moving layer’s content and selecting transform tool

I wasn’t able to replicate this but I have had instances of Krita crashing during normal usage of the Transform Tool. It’s very random, but it’s happened about thrice on me now, regardless of whether the file was big or small. This usually happened by duplicating a layer then switching to the transform tool too fast (via keyboard shortcut).

Running 4.3.0 on Linux Mint MATE 64-bit

For that pop-up error message what seems to work is:

  • Duplicate layer
  • Create a selection with the lasso tool
  • Switch to transform tool and have it calculate some transformation
  • Quickly switch to the move tool and try to drag the selected area around

Possibly easier to provoke with a larger resolution and bit depth.

Let me know if that even fits this bug, because there’s also the case when Krita crashes with
Thread 1 "AppRun" received signal SIGABRT, Aborted. 0x00007ffff355b355 in raise () from /usr/lib/libc.so.6 and I’m not sure how to reproduce that again.