SUMMARY I believe the cause is an uncaught null pointer. kis_canvas_resource_provider.cpp:178 ``` Q_ASSERT(preset->valid()); ``` STEPS TO REPRODUCE 1. Open/create a new document in Krita 2. Open the preset/brush editor 3. Click the (<) button, then click the (+) button to begin working on a new brush. I had the "Pixel Engine selected" 4. Draw something on the scratchpad to change the state of the new preset. 5. Toggle the widget's focus state (e.g. click "auto" then "pre-defined" then "auto") 6. Now an "invalid preset" indicator should be shown. If so, when you click the (+) to add a new brush preset, Krita will crash. For some reason if I am debugging the app in CLion, then this crash will kill my KDE/Plasma session except for the mouse. I must then restart. Regardless, I triggered the bug multiple times. This does not happen if I am not debugging. The CLion debugger did flag the line causing the problem. I tried submitting a report in the crash response dialog. I believe this was Dr. Konqi, but I did not find a corresponding bug in bugs.kde.org. OBSERVED RESULT Krita crashes. EXPECTED RESULT An error message halting the Q_ASSERT check before it blows up or a teardown of the new (but invalid) brush preset. SOFTWARE/OS VERSIONS Windows: n/a macOS: n/a Linux/KDE Plasma: Garuda Linux (arch) with linux 5.9.10-zen1-1-zen (available in About System) KDE Plasma Version: 5.20.3 KDE Frameworks Version: 5.76.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION
if you go through all the same steps and click the "refresh" icon beside the "invalid" icon, that is another way to hit the same bug at L:178. Also, when I am toggling through various brush presets, a similar error is being thrown for me at kis_canvas_resource_provider.cpp:198 (in the same valid() check for presets). This time, it is thrown in the `setPreviousPaintOpPreset()` member function. I am not yet sure of the proper way to address this behavior.
Created attachment 133626 [details] New crash information added by DrKonqi krita (5.0.0-prealpha (git ec43d9e)) using Qt 5.15.2 - What I was doing when the application crashed: I was clicking through the brush presets in the brush settings dialog -- Backtrace (Reduced): #7 0x00007f4c89452d59 in qt_assert_x(char const*, char const*, char const*, int) () at /usr/lib/libQt5Core.so.5 #8 0x00007f4c8d9763cd in KisCanvasResourceProvider::setPreviousPaintOpPreset(QSharedPointer<KisPaintOpPreset>) (this=<optimized out>, preset=...) at /data/dev/kritadev/krita/libs/ui/kis_canvas_resource_provider.cpp:198 #9 0x00007f4c8dca5033 in KisPaintopBox::setCurrentPaintop(QSharedPointer<KisPaintOpPreset>) (this=0x5633fe1ea200, preset=...) at /data/dev/kritadev/krita/libs/ui/kis_paintop_box.cc:623 #10 0x00007f4c8dcaa6d6 in KisPaintopBox::resourceSelected(QSharedPointer<KoResource>) (this=0x5633fe1ea200, resource=...) at /data/dev/kritadev/krita/libs/ui/kis_paintop_box.cc:594 #11 0x00007f4c8daa302e in KisPaintopBox::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (_o=<optimized out>, _c=<optimized out>, _id=<optimized out>, _a=<optimized out>) at /data/dev/kritadev/build/libs/ui/kritaui_autogen/EWIEGA46WW/moc_kis_paintop_box.cpp:242
If you're using Linux to test, X11 will hang because the brush editor is a popup. X11 blocks everything if there's a popup visibile, so if krita crashes while running in gdb and a popup is visible, X11 will hang. I start gdb from a text terminal to debug these things.
Git commit 747d5dbd59b40c6239745ef53dc74b6575a2e8a1 by Boudewijn Rempt. Committed on 25/11/2020 at 10:33. Pushed by rempt into branch 'master'. M +2 -3 libs/ui/kis_canvas_resource_provider.cpp https://invent.kde.org/graphics/krita/commit/747d5dbd59b40c6239745ef53dc74b6575a2e8a1