Bug 416000

Summary: 2 Internal Error(Safe Assert) messages when opening kra file that has vector layer
Product: [Applications] krita Reporter: acc4commissions
Component: GeneralAssignee: Halla Rempt <halla>
Status: RESOLVED FIXED    
Severity: normal CC: halla
Priority: NOR    
Version First Reported In: nightly build (please specify the git hash!)   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: Capture

Description acc4commissions 2020-01-08 13:35:20 UTC
Created attachment 124972 [details]
Capture

SUMMARY
git 0875026

STEPS TO REPRODUCE
1. Create a vector layer and save the document.
2. Open it again.
3. Error message.


SOFTWARE/OS VERSIONS
Windows: Win7
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 Halla Rempt 2020-01-08 13:38:12 UTC
Is this with the appimage? The appimages we build on the binary factory have the safe asserts disabled.
Comment 2 Halla Rempt 2020-01-08 13:46:35 UTC
Okay, see the asserts, but only on the commandline, with the appimages we build, and not in 4.2.8 -- but it is present in the 4.2 branch.
Comment 3 Halla Rempt 2020-01-08 13:59:28 UTC
Okay, this is caused by 

commit dde9dd4d0d0b4148cbfebcfb64f7a76a89c884ac (refs/bisect/bad)
Author: Ivan Yossi <ghevan@gmail.com>
Date:   Sun Jan 5 19:48:05 2020 +0000

    Delay initialization of brush paintop widget state
    
    State requires an active view in the canvas
    to change widget status.
    
    BUG:415033


Which seems completely unrelated...
Comment 4 Halla Rempt 2020-01-10 10:05:33 UTC
Git commit 7f7d98d9b1be230c0c5a95fc3809244d01f215e1 by Boudewijn Rempt.
Committed on 10/01/2020 at 10:02.
Pushed by rempt into branch 'master'.

Clear the activationLocks before deactivating the Stroke and Fill config widgets

When loading a file with a vector layer, the node manager will
activate and deactivate the default tool in the wrong order. This
cannot be worked around; and in fact, we get a LOT of activate
and deactivate calls because just creating the config widgets will
call those:

KoStrokeConfigWidget::KoStrokeConfigWidget DefaultToolTabbedWidget(0x562719ef0e00, name="default-tool-tabbed-widget")
KoFillConfigWidget::KoFillConfigWidget KoFillConfigWidget(0x562719f206a0)
KoFillConfigWidget::deactivate() KoFillConfigWidget(0x562719f206a0, name="KoFillConfigWidget")  locks: 0
KoFillConfigWidget::activate() KoFillConfigWidget(0x562719f206a0, name="KoFillConfigWidget") 2
KoStrokeConfigWidget::deActivate(): locks 0
KoFillConfigWidget::deactivate() KoFillConfigWidget(0x562719f206a0, name="KoFillConfigWidget")  locks: 0
KoFillConfigWidget::KoFillConfigWidget KoFillConfigWidget(0x56271a039190)
KoFillConfigWidget::deactivate() KoFillConfigWidget(0x56271a039190, name="KoFillConfigWidget")  locks: 0
KoFillConfigWidget::activate() KoFillConfigWidget(0x56271a039190, name="KoFillConfigWidget") 2
KoStrokeConfigWidget::activate(): locks 2
KoFillConfigWidget::activate() KoFillConfigWidget(0x562719f206a0, name="KoFillConfigWidget") 2
KoFillConfigWidget::deactivate() KoFillConfigWidget(0x56271a039190, name="KoFillConfigWidget")  locks: 0
KoStrokeConfigWidget::deActivate(): locks 0
KoFillConfigWidget::deactivate() KoFillConfigWidget(0x562719f206a0, name="KoFillConfigWidget")  locks: 0
KoFillConfigWidget::deactivate() KoFillConfigWidget(0x56271a039190, name="KoFillConfigWidget")  locks: 2
SAFE ASSERT (krita): "d->deactivationLocks.empty()" in file /home/boud/dev/krita/libs/ui/widgets/KoFillConfigWidget.cpp, line 358
KoStrokeConfigWidget::deActivate(): locks 2
SAFE ASSERT (krita): "d->deactivationLocks.empty()" in file /home/boud/dev/krita/libs/ui/widgets/KoStrokeConfigWidget.cpp, line 481

M  +1    -4    libs/ui/widgets/KoFillConfigWidget.cpp
M  +1    -4    libs/ui/widgets/KoStrokeConfigWidget.cpp

https://invent.kde.org/kde/krita/commit/7f7d98d9b1be230c0c5a95fc3809244d01f215e1