https://bugs.kde.org/show_bug.cgi?id=508785
--- Comment #2 from [email protected] --- Another update. After I applied the previous duct tape solutions, I found more oddities with Krita, luckily, observable. (Krita 5.2.11, Docker build with ASAN enabled). The problem starts during the copy action. Several seconds after Ctrl+C or the likes, something happens internally, which makes Qt clear the clipboard. In the debug build, the following message is fired 3 times: kf.imageformats.plugins.eps: Creating EPS files requires pdftops (from Poppler) or gs (from GhostScript) After some time, the clipboard ownership is lost (checked with QClipboard::ownsClipboard() during KisNodeManager::pasteLayersFromClipboard()). Interestingly, this only happens once when image selection (or its content) is renewed. Hitting Ctrl+C again, the EPS message doesn't appear, and as such the crash will not happen. Because of this, the Copy Selection to New Layer will never produce a crash, though the messages will appear. So I want to update the steps to reproduce. In any document: 1. Generate selection or use the entire canvas 2. Hit Ctrl+C or similar actions that trigger KisSelectionManager::copy() 3. Wait a few seconds 4. Hit Ctrl+V or similar actions that trigger KisSelectionManager::paste() 5. Krita pastes layers from a clipboard it doesn't own anymore, resulting in a SEGFAULT. What's more is that Krita will still paste the image (applying the fix above), but it will be pasted in the middle of the document, probably due to a lack of data. I also noticed some horrible stuttering during the whole process, maybe it is related. Lastly, I also sometimes get this during Ctrl+Z: SAFE ASSERT (krita): "!m_d->parent || !parent" in file /home/appimage/persistent/krita/libs/image/kis_paint_device.cc, line 1200 -- You are receiving this mail because: You are watching all bug changes.
