Krita/docs/Bug Writing Guidelines: Difference between revisions

From KDE Community Wiki
< Krita‎ | docs
No edit summary
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
#pragma section-numbers on
__NUMBEREDHEADINGS__
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.org/enter_bug.cgi?product=krita&format=guided Krita bug tracking system]. Thank you! You can also get assistance in the #krita channel on [irc://irc.freenode.net/krita irc.freenode.net].
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.org/enter_bug.cgi?product=krita&format=guided Krita bug tracking system]. Thank you! You can also get assistance in the #krita channel on [irc://irc.freenode.net/krita irc.freenode.net].


Line 65: Line 61:
* Linux. [http://nonaynever.ru/kwiki/krita/BugWritingGuidelines?action=AttachFile&do=get&target=bugreporting_assistant.png ''KDE Crash Handler''] caught the crash.<br>Just report the bug using the assistant or attach (not recommended) the ''Developer Information'' section to a bugreport as text.
* Linux. [http://nonaynever.ru/kwiki/krita/BugWritingGuidelines?action=AttachFile&do=get&target=bugreporting_assistant.png ''KDE Crash Handler''] caught the crash.<br>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.<br />Try to find steps to reproduce this bug. When you know exactly how to get it, run Krita under <tt>gdb</tt> and fetch the backtrace manually.
* Linux. Krita crashed and ''KDE Crash Handler'' didn't catch it.<br />Try to find steps to reproduce this bug. When you know exactly how to get it, run Krita under <tt>gdb</tt> and fetch the backtrace manually.
*# Open <tt>gdb</tt><syntaxhighlight lang="bash">
*# Open <tt>gdb</tt><syntaxhighlight lang="bash">
gdb krita
gdb krita
Line 81: Line 77:
*# Please note that <tt>gdb</tt> will ask you to press ''Enter'' key several times to show the entire backtrace (it is several windows long)
*# Please note that <tt>gdb</tt> will ask you to press ''Enter'' key several times to show the entire backtrace (it is several windows long)
*# Copy the backtrace and attach it to a bugreport
*# 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
* Windows: see https://docs.krita.org/Dr._Mingw_debugger
* Additional info about getting useful backtraces can be found at KDE's [https://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports How to create useful crash reports] tutorial
* Additional info about getting useful backtraces can be found at KDE's [https://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports How to create useful crash reports] tutorial



Latest revision as of 09:24, 30 January 2017

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 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. 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 catch 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: see https://docs.krita.org/Dr._Mingw_debugger
  • 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 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 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 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!