Created attachment 116998 [details] Krita Internal Error in kis_strokes_queue.cpp line 328 SUMMARY krita-4.2.0-pre-alpha-903fc90-x86_64.appimage (and many versions in early December 2018) crashed when doing select > copy action with multiple documents opened. I recall it first happened with nightly appimages around early December. There were all sorts of Qt related oddities across the system when it happened, too. STEPS TO REPRODUCE 1. Drag 2 documents into Krita, one .KRA file, the other .JPG 2. Use rectangular selection tool to select an area from the JPG file 3. Ctrl+C, switch to .KRA document, paste 4. Paint with brush or Resize the pasted content both triggered crashes in my case. 5. I didn't have the time to test it thoroughly. It just happened to crash 4 times when I was doing the exact same thing mentioned above. OBSERVED RESULT Krita has encountered an internal error: SAFE ASSERT (krita): "stroke" in file /home/appimage/workspace/Krita_Nightly_Appimage_Build/krita/libs/image/kis_strokes_queue.cpp, line 328 Ignore or Continue, Krita will close/crash anyway. EXPECTED RESULT Krita doesn't crash when I do such tasks. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro 18.0 KDE (available in About System) KDE Plasma Version: 5.14.4 KDE Frameworks Version: 5.52.0 Qt Version: 5.11.2 Krita: krita-4.2.0-pre-alpha-903fc90-x86_64.appimage
I forgot to mention the Qt oddities happened with it too. When I encountered this crash the first time, after Krita crashed, the whole system went nuts, none of the Qt applications worked. I could not even save a screenshot back then because of that. I restarted the system immediately, but could not reproduce the crash with the exact same steps I just did. Later when the crash happened again with krita-4.2.0-pre-alpha-903fc90-x86_64.appimage, it appears to have no such Qt oddities. Once I restarted Krita I was able to carry out the task with no problem.
does this still happen in the latest nightlies? Otherwise I am going to assign dmitry to this...
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
(In reply to wolthera from comment #2) > does this still happen in the latest nightlies? Otherwise I am going to > assign dmitry to this... I haven't been seeing this one for a while now, but I do remember I reported something similar recently, probably the same thing. And since I have been translating, not drawing lately, I don't know how it became on this front. Maybe you can let Dmitry know?
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.
Hi, Tyson! This crash might have been related to the Qt's tablet problems we had. The assert itself means that the stroke has been finished twice. That may happen, e.g. when TabletRelease event arrives twice. That was technically possible with the unpatched Qt that we had in December. I guess I should close this bug as "fixed" now. If you encounter it again, please reopen it **and** try to generate a backtrace, either with GDB or KCrash by pressing "Abort" in the assert :)
Thank you Dmitry! It's not happening now.