Jump to content

Krita/docs/Bug Writing Guidelines

From KDE Community Wiki
< Krita | docs
Revision as of 15:19, 19 June 2015 by Dmitry (talk | contribs) (Created page with "#pragma section-numbers on This page assumes you'd like to contribute to the Krita project by collecting enough information to enter a useful bug report in [https://bugs.kde....")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
  1. pragma section-numbers on

This page assumes you'd like to contribute to the Krita project by collecting enough information to enter a useful bug report in Krita bug tracking system. Thank you! You can also get assistance in the #krita channel on irc.freenode.net.

Bug report checklist

  1. Figure out the steps to reproduce a bug.
  2. Make sure your software is up to date. Ideally, test an in-development version to see whether your bug has already been fixed (e.g. Krita Lime, openSUSE, or Arch packages)
  3. Try to reset your Krita configuration files and brush presets.


After information is gathered, report the bug:

  1. Open a new bug report for each issue!
  2. Write a clear summary for each bug report
  3. Write your operating system. Windows or Linux? If Linux, how did you install Krita: official distribution packages, Krita Lime or you built manually using Krita for Cats tutorial?
  4. Write a version of your package.
  5. Provide precise steps to reproduce this bug
  6. Provide additional information if your bug is a crash, hangup, tablet related, memory consumption or performance related bug.

Writing a clear summary

  • Good: Crash when redoing after updating to Krita: 2.9.5 (git c5aba5a)
  • Bad: I painted for 5 minutes and Krita crashed

Finding out a version of Krita package

  • Go to Help->About Krita and copy or make a screenshot of a [attachment:krita_version_tag.png version tag].
  • If you are using Krita Lime, you can get a version by typing 
    dpkg -s krita-testing | grep Version
  • On Windows Kritaversion is also stored in the .msi package name.

Writing precise steps to reproduce

How can a developer reproduce the bug on his or her own computer?

Steps to reproduce are the most important part of any bug report. If a developer is able to reproduce the bug, the bug is very likely to be fixed. If the steps are unclear, it might not even be possible to know whether the bug has been fixed.

Example of a perfect bug report: 

Whenever I redo a brush stroke I get a crash (see the backtrace below).
I've updated to Krita: 2.9.5 (git c5aba5a) today.

Reproducible: Always

Steps to Reproduce:
1. fresh configs
2. make a paint stroke
3. undo
4. redo

Actual Results:  
I get a crash.

Expected Results:  
Redo the paint stroke.

Providing additional information

Crash Bug

When experiencing a crash, attach a backtrace information to the bugreport if possible.

  • Linux [attachment:bugreporting_assistant.png KDE Crash Handler] caught the crash.
    Just report the bug using the assistant or attach (not recommended) the Developer Information section to a bugreport as text.
  • Linux. Krita crashed and KDE Crash Handler didn't caught it.
    Try to find steps to reproduce this bug. When you know exactly how to get it, run Krita under gdb and fetch the backtrace manually.
    1. Open gdb
      gdb krita
    2. Run Krita 
      run
    3. If you are using Krita Lime install Krita debugging packages 
      sudo apt-get install krita-testing-dbg # or krita-2.9-dbg if you are using stable builds
    4. Try to reproduce the bug until Krita crashes
    5. When Krita crashes switch back to the terminal and generate the backtrace 
      thread apply all backtrace
    6. Please note that gdb will ask you to press Enter key several times to show the entire backtrace (it is several windows long)
    7. Copy the backtrace and attach it to a bugreport
  • Windows. Until we recover Breakpad, the only way to report a crash on Windows is to list exact steps to reproduce a crash
  • Additional info about getting useful backtraces can be found at KDE's How to create useful crash reports tutorial

Hangup Bug

When a hangup occurs you should generate a backtrace manually using gdb. Please use [#Crash_Bug Crash Bug] for the info.

  • After you started Krita under gdb and got a hangup you should switch to the terminal where gdb is running and press Ctrl+C
  • If you already got a hangup you should not restart it. Just attach gdb to it 
    gdb --pid `pidof krita`
  • Most of Ubuntu distribution forbid attaching gdb to a process by default so you might see 'ptrace: Operation not permitted' error. If so you can temporarily disable this security policy by issuing 
    echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

Tablet-related Bug

When reporting a table-related bug, make sure you attach a tablet event log, which shows developers how your tablet communicates with Krita.

Common

  • write the model and manufacturer of your tablet (e.g. Wacom, Huion, Yiynova, Genius)
  • if you have a custom stylus button assignment (e.g. your stylus button is assigned to generate Ctrl key), please make a screenshot of your Wacom settings window, so the developers could reproduce your issue.

Windows

  1. Install DebugView from the official Microsoft website
  2. Start DebugView
  3. Start Krita
  4. Press Ctrl+Shift+T, you will see a message box telling the logging is started
  5. Try to reproduce your problem
  6. Go back to DebugView and save its output to a file. Attach this file to a bug report or paste using services like paste.kde.org

Linux

  1. Open a console application (e.g. konsole in KDE)
  2. Set the amount of scrollback to 'unlimited' (for Konsole: Settings->Edit Current Profile->Scrolling->Unlimited Scrollback)
  3. Start Krita by typing krita and create any document.
  4. Press Ctrl+Shift+T, you will see a message box telling the logging is started
  5. Try to reproduce your problem
  6. The console is now filled with the log. Attach it to a bug report as a file or paste using services like paste.kde.org

Memory consumption bug

Provide the following information about your configuration:

  • Your operating system? Windows or Linux?
  • Is your system 32 bit or 64 bit?
  • How much RAM your system has?
  • What is your image size? How many layers?
  • Make a screenshot of the [attachment:memory_consumption_window.png memory consumption window] in Krita at the bottomright corner.

Painting performance bug

Provide the following information about your configuration:

  • Your operating system? Windows or Linux?
  • Is your system 32 bit or 64 bit?
  • How much RAM your system has?
  • What is your CPU?
  • What is your image size? How many layers?
  • Do you paint with a tablet device or using a mouse?
  • Make a screenshot of the [attachment:memory_consumption_window.png memory consumption window in Krita at the bottomright corner.
  • Generate a performance log showing the response times of Krita strokes
    1. Go to Settings->Configure Krita...->Performance
    2. Activate 'Enable performance logging' checkbox
    3. Close Krita
    4. Open console and switch to your home directory with 
      cd ~
    5. Start Krita from this console by typing 
      krita
    6. Paint as usual. You should do as many "usual" strokes as possible. Preferably, you should emulate how you usually paint and use brushes you use the most.
    7. Close Krita
    8. Now in your home directory you have a folder named log with your brush presets and timing information. Compress it and attach to a bug.
    9. Don't forget to disable performance logging when you return back to production work!
Retrieved from "https://community.kde.org/index.php?title=Krita/docs/Bug_Writing_Guidelines&oldid=42693"