Created attachment 122304 [details] krita crash log SUMMARY krita crashes when using color selector in the top toolbar STEPS TO REPRODUCE 1. open color selector through top toolbar 2. pick a color on the gradient scale or through the swatches to the right of the gradient 3. OBSERVED RESULT occasionally, krita suddenly closes after selecting a color. EXPECTED RESULT the color should be available to use or i should be able to continue selecting a color SOFTWARE/OS VERSIONS Windows: Windows 7sp1 (x86_64) macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION it doesn't crash every time i pick a color. i seem to be able to use the color selector several times before krita crashes. it seems to vary on how many times i can adjust the color on the gradient or in the swatches when choosing a color before crashing.
Settings this to confirmed. Weirdly seems to crash in the qwidget paintevent of all places.
Hi, Thanks for the crash log. Could you please also attach the contents of Help->System Information for Bug Reports to this bug? I haven't seen this crash before, and it's all inside the development toolkit, not Krita's code.
Created attachment 122389 [details] system information
Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information.
This crash still puzzles me, all my attempts to find the cause failed so far. First of all, I also have the issue with the 4.2.x appimages on (K)Ubuntu 18.04, but only with those. I tried self-compiled master, 4.2.x from krita lime PPA, 4.1.x appimages (that for some reason fail to use OpenGL) and 4.0.4 appimage. I couldn't get any of them to crash, leading me to believe the issue is somehow related of Qt 5.12 used for the 4.2 builds. What's also strange is that it's only the non-modal dialog used to select foreground color, the background color dialog is not crashing here. I also want to add that for me, the foreground color dialog doesn't render at all anymore once it had been closed until you resize the window. Just the window frame/shadow renders on opening, but inside is just frozen to whatever happened to be on screen already until resizing it. Resizing the dialog like mad seems to be the easiest way to make it crash. However, all version I tested sometimes print this a couple of times on resizing, but am not sure from which widget it comes from: QPainter::begin: Paint device returned engine == 0, type: 2 QPainter::setPen: Painter not active QPainter::setBrush: Painter not active QPainter::setRenderHint: Painter must be active to set rendering hints So something in code must also be wrong, but so far I don't see how that could be related to random crashes deep in the guts of Qt, doesn't even seem correlated in time. If I could at least make a build myself that crashes, I could test if my branch with the reworked code still has this issue or not...
If I look at the system information and the crash log, I am beginning to suspect that switching to Angle will kind of avoid the crash. It's an Intel system using opengl directly, and the first crash is in the opengl driver. Allie, could you check whether changing the renderer in settings->configure Krita->display from opengl to Angle makes a difference?
Created attachment 122463 [details] backtrace + sytem info (4.2.6-beta appimage) I looked at the attached crash log again, there's 4 crashes logged and only the first was in OpenGL stuff, the other 3 look very similar to mine despite different platforms, involving QWidgetPrivate::syncBackingStore() and QWidget::mapTo()
(In reply to Boudewijn Rempt from comment #6) > If I look at the system information and the crash log, I am beginning to > suspect that switching to Angle will kind of avoid the crash. It's an Intel > system using opengl directly, and the first crash is in the opengl driver. > > Allie, could you check whether changing the renderer in settings->configure > Krita->display from opengl to Angle makes a difference? changing it to angle seems to have helped. i opened the color picker and changed the color about 20 times with no crashes.
(In reply to Boudewijn Rempt from comment #6) > If I look at the system information and the crash log, I am beginning to > suspect that switching to Angle will kind of avoid the crash. It's an Intel > system using opengl directly, and the first crash is in the opengl driver. > > Allie, could you check whether changing the renderer in settings->configure > Krita->display from opengl to Angle makes a difference? just had a crash while using the color picker with angle. i've attached the most recent crash log
Created attachment 122572 [details] krita crash log 9-9
I am 99% sure by now that the cause is this Qt bug: https://bugreports.qt.io/browse/QTBUG-76923 It's a regression in 5.12.4 from an attempt to to fix a regression from 5.11, but ended up making things much worse. It is already reverted in Qt git for 5.12.5, which hopefully releases any day now (like, it's actually planned for today if I take EU time), I hope krita 4.2.6 can be built with that. Otherwise we'd have to consider a work around, in theory deleting and recreating the dialog on each use should work, but from reading that bug, other things like floating dock widgets are prone to crashes too with that bug.
I can also reproduce this bug on Linux, both in AppImage and in ext-cmake build. I'll mark the bug as a regression and release blocker
Well, dammit... We have just released, I cannot undo that...
But I cannot reproduce this with the 4.2.6 appimage...
If Lynx3d could reproduce, we can consider this confirmed for now.