< Krita | docs 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. Contents 1 Bug report checklist 2 Writing a clear summary 3 Finding out a version of Krita package 4 Writing precise steps to reproduce 5 Providing additional information 5.1 Crash Bug 5.2 Hangup Bug 5.3 Tablet-related Bug 5.3.1 Common 5.3.2 Windows 5.3.3 Linux 5.4 Memory consumption bug 5.5 Painting performance bug 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 gdbgdb 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 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 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! Retrieved from "https://community.kde.org/index.php?title=Krita/docs/Bug_Writing_Guidelines&oldid=76104" This page was last edited on 30 January 2017, at 09:24. Content is available under Creative Commons License SA 4.0 unless otherwise noted.