Krita/docs/Bug Writing Guidelines: Difference between revisions
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...." |
|||
| (10 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
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 25: | Line 23: | ||
== Finding out a version of Krita package == | == Finding out a version of Krita package == | ||
* Go to <tt>Help->About Krita</tt> and copy or make a screenshot of a [ | * Go to <tt>Help->About Krita</tt> and copy or make a screenshot of a [http://nonaynever.ru/kwiki/krita/BugWritingGuidelines?action=AttachFile&do=get&target=krita_version_tag.png version tag]. | ||
* If you are using Krita Lime, you can get a version by typing <syntaxhighlight lang="bash"> | * If you are using Krita Lime, you can get a version by typing <syntaxhighlight lang="bash"> | ||
dpkg -s krita-testing | grep Version | dpkg -s krita-testing | grep Version | ||
| Line 61: | Line 59: | ||
When experiencing a crash, attach a backtrace information to the bugreport if possible. | When experiencing a crash, attach a backtrace information to the bugreport if possible. | ||
* Linux [ | * 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 | * 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 79: | 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. | * 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 | ||
=== Hangup Bug === | === Hangup Bug === | ||
When a hangup occurs you should generate a backtrace manually using <tt>gdb</tt>. Please use [#Crash_Bug Crash Bug] for the info. | When a hangup occurs you should generate a backtrace manually using <tt>gdb</tt>. Please use [[#Crash_Bug|Crash Bug]] for the info. | ||
* After you started Krita under <tt>gdb</tt> and got a hangup you should switch to the terminal where <tt>gdb</tt> is running and press ''Ctrl+C'' | * After you started Krita under <tt>gdb</tt> and got a hangup you should switch to the terminal where <tt>gdb</tt> is running and press ''Ctrl+C'' | ||
| Line 122: | Line 120: | ||
* How much RAM your system has? | * How much RAM your system has? | ||
* What is your image size? How many layers? | * What is your image size? How many layers? | ||
* Make a screenshot of the [ | * Make a screenshot of the [http://nonaynever.ru/kwiki/krita/BugWritingGuidelines?action=AttachFile&do=get&target=memory_consumption_window.png memory consumption window] in <tt>Krita</tt> at the bottomright corner. | ||
=== Painting performance bug === | === Painting performance bug === | ||
| Line 132: | Line 130: | ||
* What is your image size? How many layers? | * What is your image size? How many layers? | ||
* Do you paint with a tablet device or using a mouse? | * Do you paint with a tablet device or using a mouse? | ||
* Make a screenshot of the [ | * Make a screenshot of the [http://nonaynever.ru/kwiki/krita/BugWritingGuidelines?action=AttachFile&do=get&target=memory_consumption_window.png memory consumption window] in <tt>Krita</tt> at the bottomright corner. | ||
* Generate a performance log showing the response times of Krita strokes | * Generate a performance log showing the response times of Krita strokes | ||
*# Go to <tt>Settings->Configure Krita...->Performance</tt> | *# Go to <tt>Settings->Configure Krita...->Performance</tt> | ||
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
- Figure out the steps to reproduce a bug.
- 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)
- Try to reset your Krita configuration files and brush presets.
After information is gathered, report the bug:
- Open a new bug report for each issue!
- Write a clear summary for each bug report
- 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?
- Write a version of your package.
- Provide precise steps to reproduce this bug
- 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.- Open gdb
gdb krita - Run Krita
run
- 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
- Try to reproduce the bug until Krita crashes
- When Krita crashes switch back to the terminal and generate the backtrace
thread apply all backtrace
- Please note that gdb 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
- Open gdb
- 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
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
- Install DebugView from the official Microsoft website
- Start DebugView
- Start Krita
- Press Ctrl+Shift+T, you will see a message box telling the logging is started
- Try to reproduce your problem
- 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
- Open a console application (e.g. konsole in KDE)
- Set the amount of scrollback to 'unlimited' (for Konsole: Settings->Edit Current Profile->Scrolling->Unlimited Scrollback)
- Start Krita by typing krita and create any document.
- Press Ctrl+Shift+T, you will see a message box telling the logging is started
- Try to reproduce your problem
- 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
- Go to Settings->Configure Krita...->Performance
- Activate 'Enable performance logging' checkbox
- Close Krita
- Open console and switch to your home directory with
cd ~
- Start Krita from this console by typing
krita
- 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.
- Close Krita
- 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.
- Don't forget to disable performance logging when you return back to production work!